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(54) Systems and methods for providing security in a video game system 



(57) A video game system includes a game system 
includes a game cartridge (54) which is pluggably at- 
tached to a main console (52) having a main processor 
(100), a 3D graphics generating coprocessor (200), ex- 
pandable main memory (300) and player controllers. A 
multifunctional peripheral processing subsystem (138) 
external to the game microprocessor and coprocessor 
is described which executes commands for handling 
player controller input/output to thereby lessen the 
processing burden on the graphics processing subsys- 
tem. The player controller processing subsystem is 
used for both controlling player controller input/output 
processing and for performing game authenticating se- 
curity checks continuously during game play. The pe- 
ripheral interface (138) includes a micro-processor 
(250) for controlling various peripheral interface func- 
tions, a read/write random access memory (264), a boot 



ROM (262), a coprocessor command channel interlace, 
a player controller channel interface, etc., which com- 
ponents interact to efficiently process player controller 
commands while also performing other important func- 
tions without requiring significant main processor 
processing time. A peripheral interface macro may be 
executed to start a read or write transaction with each 
peripheral device and thereafter transfer the transaction 
results stored in the random access memory to the 
game microprocessor. The peripheral interface (138) 
performs security in addition to input/output functions. 
The peripheral interface interacts with a security micro- 
processor chip within an external storage unit. The video 
game system authenticates the security microprocessor 
chip, and also authenticates the video game program 
stored on a storage medium within the external storage 
unit. 
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Description 

FIELD OF THE INVENTION 

5 The present invention relates to a high performance low cost video game system. More particularly, the invention 

relates to a video game system having a multifunctional player controller processing subsystem with security features, 
and a flexibly expandable video game external memory with a low pin out. 

BACKGROUND AND SUMMARY OF THE INVENTION 

10 

Microprocessor-based home video game systems such as the Nintendo Entertainment System and the Super 
Nintendo Entertainment System have been highly successful in part because they can interactively produce exciting 
video graphics involving numerous animated moving objects. 

The video game system described herein and in further detail in a concurrently filed patent application, which has 
is been incorporated herein by reference and names Van Hook et al as inventors, permits game play involving three- 
dimensional images having a depth and realism far exceeding these and other heretofore known video game systems. 
In the past, computer systems required to produce such images interactively costs tens of thousands of dollars. 

In order to provide such a high performance video game system at a cost affordable to the average consumer, 
many features in the video game system were uniquely optimized. In so doing, many unique features were incorporated 
20 into the system described herein using novel, multifunctional components having a tow pinout, but which provide for 
highly flexible future expansion. 

The processor and/or picture processing unit of video game systems such as the Nintendo Entertainment System 
and the Super Nintendo Entertainment System exercise direct control over processing of signals from player input/ 
game control devices, i.e., player controllers. These prior art systems do not include a player controller processing 
25 subsystem which coacts with the game microprocessor and picture processing unit to process commands for handling 
player controller related input/output. 

The present invention is directed in part to a multifunctional peripheral processing subsystem external to the game 
microprocessor and disclosed coprocessor which executes commands for handling player controller input/output to 
thereby lessen the processing burden on the graphics processing subsystem. The peripheral processing subsystem 
30 is used for both controlling player controller input/output processing and for performing game authenticating security 
checks continuously during game play. The peripheral processing subsystem is also used during the game cartridge/ 
video game system console initial communication protocol using instructions stored in its boot ROM to enable initial 
game play. 

The peripheral interface is coupled to the coprocessor by a three bit wide serial bus over which commands are 
35 received over one line, clock signals over another line and responses are transmitted to the coprocessor over a third 
serial line. The peripheral interface includes a microprocessor for controlling various peripheral interface functions, a 
read/write random access memory, a boot ROM, a coprocessor command channel interface, a player controller channel 
interface, etc., which components interact to efficiently process player controller commands while also performing other 
important functions without requiring significant main processor processing time. 
40 The coprocessor command channel interface responds to coprocessor clock and command control signals to 

permit access to the random access memory and to the boot ROM and generates control signals to interrupt the 
peripheral interface microprocessor. A peripheral interface macro may be executed to start a read or write transaction 
with each peripheral device and thereafter transfer the transaction results stored in the random access memory to the 
game microprocessor main memory. 
45 in accordance with another aspect of the present invention, a portable storage device is used in the form of a game 

cartridge in the exemplary embodiment having a low pinout due in part to the use of a multiplexed address/data bus. 
Memory access related timing signals are transmitted to the cartridge which may be programmably varied depending 
upon detected address domain which is used to establish the type of storage device being used by the video game 
system. 

50 

BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features and advantages of the present invention will be better and more completely understood 
by referring to the following detailed description of a presently preferred exemplary embodiment in connection with the 
55 drawings, of which: 

Figure 1 is a perspective view of an exemplary embodiment of a video game system in accordance with the present 
invention; 
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Figure 2 is a block diagram of a video game console and game cartridge shown in Figure 1 ; 

Figure 3A is a block diagram of reset related circuitry embodied in the video game console shown in Figure 2; 

Figure 3B depicts timing signals generated by the circuitry of Figure 3A; 

Figures 4A and 4B is an exemplary, more detailed, implementation of the vide game console as shown in the 
5 Figure 2 block diagram; 

Figure 5A shows exemplary signals appearing on the communication channel between the coprocessor in the 
peripheral interface subsystem; 

Figure 5B depicts exemplary timing signals for illustrative commands communicated on this communication chan- 
nel; 

10 Figures 6A-F show exemplary 3D screen effects achievable using the system described herein. 

Figure 7 is a block diagram of the peripheral interface shown in Figure 2; 
Figure 8 depicts in further detail the PIF channel interface shown in Figure 7; 

Figure 9A is a block diagram showing in further detail the joystick channel controller in one of the ports depicted 
in the block diagram of Figure 7; 
is Figure 9B is an illustrative representation of data from a player controller communicated to the peripheral interface 

138; 

Figures 10A through 10C are flowcharts depicting the sending and receiving modes of operation for the player 
controller channel shown in Figure 7; 

Figure 11 shows an exemplary player controller with a memory card; 
20 Figure 1 2 is a block diagram of an exemplary cartridge memory device and associated accessing circuitry; 

Figures 1 3 and 14 are exemplary timing control and data signals associated with the memory system depicted in 
Figure 12; 

Figure 15 shows an example process for manufacturing external storage units embodying security features; 
Figures 1 6A-1 6F show an example embodiment of an overall video game security arrangement that tests whether 
25 a video game program and storage unit security chip match; 

Figure 17 shows an additional video game security arrangement embodiment; 
Figure 1 8 shows a still additional video game security arrangement embodiment; 

Figure 1 9 is a simplified flowchart of a further embodiment of example security steps performed by a video game 
main processor; 

30 Figures 20A-20C are a simplified flowchart of a further embodiment of example security steps performed by a 

video game peripheral interface; and 

Figure 21 is a simplified flowchart of a further embodiment of exmaple security steps performed by a video game 
security chip. 

35 DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENT 

Figure 1 shows an exemplary embodiment of a video game system 50 in accordance with the present invention. 
Illustrative video game system 50 includes a main console 52, a video game storage device 54, and handheld controllers 
56a,b (or other user input devices). Main console 52 is connected to a conventional home color television set 58. 
40 Television set 58 displays 3D video game images on its television screen 60 and reproduces stereo sound through its 
speakers 62a,b. 

In the illustrative embodiment, the video game storage device 54 is in the form of a replaceable memory cartridge 
insertable into a slot 64 on a top surface 66 of console 52. A wide variety of alternative program storage media are 
contemplated by the present invention such as CD ROM, floppy disk, etc. In this exemplary embodiment, video game 

45 storage device 54 comprises a plastic housing 68 encasing a printed circuit board 70. Printed circuit board 70 has an 
edge 72 defining a number of electrical contacts 74. When the video game storage device 68 is inserted into main 
console slot 64, the cartridge electrical contacts 74 mate with corresponding "edge connector" electrical contacts within 
the main console. This action electrically connects the storage device printed circuit board 72 to the electronics within 
main console 52. In this example, at least a "read only memory" chip 76 is disposed on printed circuit board 70 within 

so storage device housing 68. This "read only memory" chip 76 stores instructions and other information pertaining to a 
particular video game. The read only memory chip 76 for one game cartridge storage device 54 may, for example, 
contain instructions and other information for an adventure game while another storage device 54 may contain instruc- 
tions and information to play a car race game, an educational game, etc. To play one game as opposed to another 
game, the user of video game system 60 need only plug the appropriate storage device 54 into main console slot 64 

55 - thereby connecting the storage device's read only memory chip 76 (and any other circuitry it may contain) to console 
52. This enables a computer system embodied within console 52 to access the information contained within read only 
memory 76, which information controls the console computer system to play the appropriate video game by displaying 
images and reproducing sound on color television set 58 as specified under control of the read only memory game 
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program information. 

To set up the video game system 50 for game play, the user first connects console 52 to color television set 58 by 
hooking a cable 78 between the two. Console 52 produces both Video 0 signals and "audio" signals for controlling color 
television set 58. The "video" signals control the images displayed on the television screen 60 and the "audio" signals 

5 are played back as sound through television loudspeaker 62. Depending on the type of color television set 58, it may 
be necessary to connect a conventional "RF modulator" between console 52 and color television set 58. This "RF 
modulator" (not shown) converts the direct video and audio outputs of console 52 into a broadcast type television signal 
(e.g., for a television channel 2 or 3) that can be received and processed using the television set's internal "tuner." 
Other conventional color television sets 58 have direct video and audio input jacks and therefore donl need this inter- 
im median/ RF modulator. 

The user then needs to connect console 52 to a power source. This power source may comprise a conventional 
AC adapter (not shown) that plugs into a standard home electrical wall socket and converts the house voltage into a 
lower voltage DC signal suitable for powering console 52. The user may then connect up to 4 hand controllers 56a, 
56b to corresponding connectors 80a-80d on main unit front panel 82. Controllers 56 may take a variety of forms. In 

is this example, the controllers 56a,b include various function controlling push buttons such as 84a-c and X-Y switches 
86a,b used, for example, to specify the direction (up, down, left or right) that a player controllable character displayed 
on television screen 60 should move. Other controller possibilities include joysticks, mice pointer controls and a wide 
range of other conventional user input devices. 

The present system has been designed to accommodate expansion to incorporate various types of peripheral 

20 devices yet to be specified. This is accomplished by incorporating a programmable peripheral device input/output 
system (to be described in detail below) which permits device type and status to be specified by program commands. 

In use, a user selects a storage device 54 containing a desired video game, and inserts that storage device into 
console slot 64 (thereby electrically connecting readonly memory 76 and other cartridge electronics to the main console 
electronics). The user then operates a power switch 88 to turn on the video game system 50 and operates controllers 

25 86a,b (depending on the particular video game being played, up to four controllers for four different players can be 
used with the illustrative console) to provide inputs to console 52 and thus control video game play. For example, 
depressing one of push buttons 84a-c may cause the game to start playing. Moving directional switch 86 may cause 
animated characters to move on the television screen 60 in controllabiy different directions. Depending upon the par- 
ticular video game stored within the storage device 54, these various controls 84, 86 on the controller 56 can perform 

30 different functions at different times. If the user wants to restart game play from the beginning, or alternatively with 
certain game programs reset the game to a known continuation point, the user can press a reset button 90. 

Figure 2 is a block diagram of an illustrative embodiment of console 52 coupled to a game cartridge 54 and shows 
a main processor 100, a coprocessor 200, and main memory 300 which may include an expansion module 302. Main 
processor 100 is a computer that executes the video game program within storage device 54. In this example, the 

35 main processor 100 accesses this video game program through the coprocessor 200 over a communication path 102 
between the main processor and the coprocessor 200, and over another communication path 104a,b between the 
coprocessor and the video game storage device 54. Alternatively, the main processor 100 can control the coprocessor 
200 to copy the video game program from the video game storage device 54 into main memory 300 over path 106, 
and the main processor 100 can then access the video game program in main memory 300 via coprocessor 200 and 

40 paths 102, 106. Main processor 100 accepts inputs from game controllers 56 during the execution of the video game 
program. 

Main processor 100 generates, from time to time, lists of instructions for the coprocessor 200 to perform. Coproc- 
essor 200, in this example, comprises a special purpose high performance, application specific integrated circuit having 
an internal design that is optimized for rapidly processing 3D graphics and digital audio information. In the illustrative 

45 embodiment, the coprocessor described herein is the product of a joint venture between Nintendo Company Limited 
and Silicon Graphics, Inc. For further details of exemplary coprocessor hardware and software beyond that expressly 
disclosed in the present application, reference is made to copending application Serial No. 08/ , naming VanHook 
et al as inventors of the subject matter claimed therein, which is entitled "High Performance Low Cost Video Game 
System With Coprocessor Providing High Speed Efficient 3D Graphics and Digital Audio Signal Processing" (Attorney 

50 Docket 723-425) filed concurrently herewith, which application is expressly incorporated herein by reference. The 
present invention is not limited to use with the above-identified coprocessor. Any compatible coprocessor which sup- 
ports rapid processing of 3D graphics and digital audio may be used herein, in response to instruction lists provided 
by main processor 100 over path 102, coprocessor 200 generates video and audio outputs for application to color 
television set 58 based on data stored within main memory 300 and/or video game storage device 54. 

55 Figure 2 also shows that the audio video outputs of coprocessor 200 are not provided directly to television set 58 

in this example, but are instead further processed by external electronics outside of the coprocessor. In particular, in 
this example, coprocessor 200 outputs its audio and video information in digital form, but conventional home color 
television sets 58 require analog audio and video signals. Therefore, the digital outputs of coprocessor 200 must be 



4 



EP0 875 816 A2 

converted into analog form - a function performed for the audio information by DAC and mixer amp 40 and for the 
video information by VDAC and encoder 1 44. The analog audio signals generated in DAC 1 40 are amplified and filtered 
by an audio amplifier therein that may also mix audio signals generated externally of console 52 via the EXTSOUND 
L7R signal from connector 154. The analog video signals generated in VDAC 144 are provided to a video encoder 

s therein which may, for example, convert "RGB" inputs to composite video outputs compatible with commercial TV sets. 
The amplified stereo audio output of the amplifier in ADAC and mixer amp 1 40 and the composite video output of video 
DAC and encoder 144 are provided to directly control home color television set 58. The composite synchronization 
signal generated by the video digital to analog converter in component 144 is coupled to its video encoder and to 
external connector 154 for use, for example, by an optional light pen or photogun. 

10 Figure 2 also shows a clock generator 1 36 (which, for example : may be controlled by a crystal 1 48 shown in Figure 

4A) that produces timing signals to time and synchronize the other console 52 components. Different console compo- 
nents require different clocking frequencies, and clock generator 136 provides suitable such clock frequency outputs 
(or frequencies from which suitable clock frequencies can be derived such as by dividing). 

In this illustrative embodiment, game controllers 56 are not connected directly to main processor 100, but instead 

is are connected to console 52 through serial peripheral interface 138. Serial peripheral interface 138 demultiplexes serial 
data signals incoming from up to four or five game controllers 56 (e.g., 4 controllers from serial I/O bus 151 and 1 
controller from connector 154) and provides this data in a predetermined format to main processor 1 00 via coprocessor 
200. Serial peripheral interface 1 38 is bidirectional, i.e., it is capable of transmitting serial information specified by main 
processor 100 out of front panel connectors 80a-d in addition to receiving serial information from those front panel 

20 connectors. The serial interface 1 38 receives main memory RDRAM data, clock signals, commands and sends data/ 
responses via a coprocessor serial interface (not shown). I/O commands are transmitted to the serial interface 1 38 for 
execution by its internal processor as will be described below. In this fashion, the peripheral interface's processor (250 
in Figure 7) by handling I/O tasks, reduces the processing burden on main processor 100. As is described in more 
detail below in conjunction with Figure 7, serial peripheral interface 1 38 also includes a "boot ROM (read only memory) 

25 a that stores a small amount of initial program load (IPL) code. This IPL code stored within the peripheral interface boot 
ROM is executed by main processor 1 00 at time of startup and/or reset to allow the main processor to begin executing 
game program instructions 108 within storage device 54. The initial game program instructions 1 08 may, in turn, control 
main processor 100 to initialize the drivers and controllers it needs to access main memory 300. 

In this exemplary embodiment, serial peripheral interface 138 includes a processor (see 250 in Figure 7) which, 

30 in addition to performing the I/O tasks referred to above, also communicates with an associated security processor 
152 within storage device 54. This pair of security processors (one in the storage device 54, the other in the console 
52) performs, in cooperation with main processor 1 00, an authentication function to ensure that only authorized storage 
devices may be used with video game console 52. 

As shown in Figures 2 and 3A, peripheral interface 1 38 receives a power-on reset signal from reset IC 1 39. Reset 

35 |C 1 39 detects an appropriate threshold voltage level and thereafter generates a power-on reset signal which, in turn, 
results in a cold reset signal being generated by circuit 1 62, which signal is coupled to the reset input of main processor 
1 00. In order to ensure that the cold reset signal is generated at the proper time, a delaying signal CLDCAP is coupled 
to cold reset signal generating circuit 162. Cold reset signal generator 162 includes a Schmidt trigger circuit (which 
receives the reset IC signal from reset IC 1 39) whose output is coupled to one input of an AND gate. The output of the 

40 Schmidt trigger is also coupled to a buffer inverter whose output and the CLDCAP signal are coupled to a second input 
of the AND gate. The output of the AND gate serves as the cold reset signal which is coupled to microprocessor 250 
and main processor 100 and microprocessor 152 shown in Figure 3A. The cold reset signal generated by the cold 
reset signal generator is fed back to the input of generator 162 through a diode (not shown). The cold reset signal is 
also coupled to the reset input of the processor 250 embodied within the peripheral interface 138 (see Figure 7) and 

45 to the reset pin of connector 154 which is coupled to the reset input of security processor 152. Figure 3B shows the 
reset IC (RESIC) : cold reset (CLDRES) and CLDCAP signals. Although signals shown in Figures 3B, 4A, 4B, etc. are 
referenced in the specification (and in Figures 2 and 3A) without regard to whether they are inverted or not (for ease 
of reference), Figures 3B, 4A and 4B and each of the timing diagrams in this disclosure indicate the appropriate inverted 
nature of the signal by a line over the signal (or pin) designation as is conventional. 

50 Figure 2 also shows a connector 154 within video game console 52. In this illustrative embodiment, connector 154 

connects, in use, to the electrical contacts 74 at the edge 72 of storage device printed circuit board 70. Thus, connector 
1 54 electrically connects coprocessor 200 to storage device ROM 76. Additionally, connector 1 54 connects the storage 
device security processor 152 to main unit serial peripheral interface 138. Although connector 154 in the particular 
example shown in Figure 2 may be used primarily to read data and instructions from a non-writable read only memory 

55 76, system 52 is designed so that the connector is bidirectional, i.e., the main unit can send information to the storage 
device 54 for storage in random access memory 77 in addition to reading information from it. 

Main memory 300 stores the video game program in the form of CPU instructions 1 08. All accesses to main memory 
300 are through coprocessor 200 over path 106. These CPU instructions are typically copied from the game program/ 
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data 108 stored in storage device 54 and downloaded to RDRAM 300. This architecture is likewise readily adaptable 
for use with CD ROM or other bulk media devices. Although CPU 100 is capable of executing instructions directly out 
of storage device ROM 76, the amount of time required to access each instruction from the ROM is much greater than 
the time required to access instructions from main memory 300. Therefore, main processor 100 typically copies the 
s game program/data 1 08 from ROM 76 into main memory 300 on an as-needed basis in blocks, and accesses the main 
memory 300 in order to actually execute the instructions. Memory RD RAM 300 is preferably a fast access dynamic 
RAM capable of achieving 500 Mbytes/second access times such as the DRAM sold by RAMBUS, Inc. The memory 
300 is coupled to coprocessor 200 via a unified nine bit wide bus 1 06, the control of which is arbitrated by coprocessor 
200. The memory 300 is expandable by merely plugging, for example, an 8 Mbyte memory card into console 52 via a 
10 console memory expansion port (not shown). 

As described in the copending Van Hook et al application, the main processor 100 preferably includes an internal 
cache memory (not shown) used to further decrease instruction access time. Storage device 54 also stores a database 
of graphics and sound data 1 1 2 needed to provide the graphics and sound of the particular video game. Main processor 
100, in general, reads the graphics and sound data 112 from storage device 54 on an as-needed basis and stores it 
is into main memory 300 in the form of texture data, sound data and graphics data. In this example, coprocessor 200 
includes a display processor having an internal texture memory into which texture data is copied on an as-needed 
basis for use by the display processor. 

As described in the copending Van Hook et al application, storage device 54 also stores coprocessor microcode 
1 56. In this example, a signal processor within coprocessor 200 executes a computer program in order to perform its 
20 various graphics and audio functions. This computer program, called the "microcode," is provided by storage device 
54, Ty*. jally, main processor 100 copies the microcode 156 into main memory 300 at the time of system startup, and 
then controls the signal processor to copy parts of the microcode on an as-needed basis into an instruction memory 
within signal processor for execution. Because the microcode 156 is provided by storage device 54, different storage 
devices can provide different microcodes - thereby tailoring the particular functions provided by coprocessor 200 under 
2$ software control. Because the microcode 156 is typically too large to fit into the signal processor's internal instruction 
memory all at once, different microcode pages or portions may need to be loaded from main memory 300 into the 
signal processor's instruction memory as needed. For example, one part of the microcode 156 may be loaded into 
signal processor 400 for graphics processing, and another part of microcode may be loaded for audio processing. See 
the above-identified related application for further details relating to the signal processor, and display processor em- 
30 bodied within the coprocessor as well as the various data bases maintained in RD RAM 300. 

Although not shown in Figure 2, as described in the copending van Hook et al application, coprocessor 200 also 
includes a CPU interface, a serial interface, a parallel peripheral interface, an audio interface, a video interface, a main 
memory DRAM controller/interface, a main internal bus and timing control circuitry. The coprocessor main bus allows 
each of the various main components within coprocessor 200 to communicate with one another. The CPU interface is 
35 the gateway between main processor 100 and coprocessor 200. Main processor 100 reads data to and writes data 
from coprocessor CPU interface via a CPU-to-coprocessor bus. A coprocessor serial interface provides an interface 
between the serial peripheral interface 1 38 and coprocessor 200, while coprocessor parallel peripheral interface 206 
interfaces with the storage device 54 or other parallel devices connected to connector 154. 

A coprocessor audio interface reads information from an audio buffer within main memory 300 and outputs it to 
40 audio DAC 140. Similarly, a coprocessor video interface reads information from an RDRAM frame buffer and then 
outputs it to video DAC 1 44. A coprocessor DRAM controller/interface is the gateway through which coprocessor 200 
accesses main memory 300. The coprocessor timing circuitry receives clocking signals from clock generator 1 36 and 
distributes them (after appropriate dividing as necessary) to various other circuits within coprocessor 200. 

Main processor 100 in this example is a MIPS R4300 RISC microprocessor designed by MIPS Technologies, Inc., 
45 Mountain View, California. For more information on main processor 100, see, for example, Heinrich, MIPS Microproc- 
essor R4000 User's Manual (MIPS Technologies, Inc., 1984, Second Ed.). 

As described in the copending Van Hook et al application, the conventional R4300 main processor 100 supports 
six hardware interrupts, one internal (timer) interrupt, two software interrupts, and one non-maskable interrupt (NMI). 
In this example, three of the six hardware interrupt inputs (INTO, INT1 and INT2) and the non-maskable interrupt (NMI) 
50 input allow other portions of system 50 to interrupt the main processor. Specifically main processor INTO is connected 
to allow coprocessor 200 to interrupt the main processor, the main processor interrupt INT1 is connected to allow 
storage device 54 or other external devices to interrupt the main processor, and main processor interrupts INT2 and 
NMI are connected to allow the serial peripheral interface 1 38 to interrupt the main processor. Any time the processor 
is interrupted, it looks at an internal interrupt register to determine the cause of the interrupt and then may respond in 
55 an appropriate mapner (e.g., to read a status register or perform other appropriate action). All but the NMI interrupt 
input from serial peripheral interface 1 38 are maskable (i.e., the main processor 100 can selectively enable and disable 
them under software control). 

When the video game reset switch 90 is pressed, a non-maskable interrupt signal is generated by peripheral 
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interface circuit 138 and is coupled to main processor 100 as shown in Figure 2. The NMI signal, however, results in 
non-maskable, immediate branching to a predefined initialization state. In order to permit the possibility of responding 
to reset switch 90 actuation by branching, for example, to the current highest game level progressed to, the circuit 
shown in Figure 3A is used. When the reset switch 90 is depressed, I/O port 164 receives a reset switch input signal 
s which sets a logic circuit therein and immediately couples an INT2 signal to processor 100. INT2 is an NMI pre-warning 
signal and is used to, for example, trigger game processor 1 00 to save the state of the game in predetermined registers. 
The logic circuit within VO port 164 may be a time delay circuit that ensures that the NMI signal occurs five seconds 
after INT2, as can be seen from the timing signals shown in Figure 3B. The left hand portion of Figure 3B shows the 
signal generation when the reset switch is pushed for less than one-half second. The right hand portion of Figure 3B 
10 shows the timing when the reset switch is pushed for greater than one-half second. Thus, an individual game program 
can designate a desired response to depressing the reset switch 90 by executing a predefined set of instructions in 
response to the INT2 signal before the occurrence of NMI. The CPU 100 also responds to the pre- NMI warning signal 
INT2 by initiating shut down processing for related audio and video systems and preparing for its cache memory and 
other circuits to shut down so that a return is possible to a desired known state other than merely the beginning of the 
is game. The NMI signal is also coupled to the peripheral interface microprocessor 250. 

In operation, as described in detail in the copending Van Hook et al application, main processor 1 00 receives inputs 
from the game controllers 56 and executes the video game program provided by storage device 54 to provide game 
processing, animation and to assemble graphics and sound commands. The graphics and sound commands generated 
by main processor 100 are processed by coprocessor 200. In this example, the coprocessor performs 3D geometry 
20 transformation and lighting processing to generate graphics display commands which the coprocessor then uses to 
"draw" polygons for display purposes. As indicated above, coprocessor 200 includes a signal processor and a display 
processor. 3D geometry transformation and lighting is performed in this example by the signal processor and polygon 
rasterization and texturing is performed by display processor 500. Display processor writes its output into a frame buffer 
in main memory 300. This frame buffer stores a digital representation of the image to be displayed on the television 
25 screen 60. Further circuitry within coprocessor 200 reads the information contained in the frame buffer and outputs it 
to television 58 for display. Meanwhile, the signal processor also processes sound commands received from main 
processor 1 00 using digital audio signal processing techniques. The signal processor writes its digital audio output into 
main memory 300, with the main memory temporarily "buffering" (i.e., storing) the sound output. Other circuitry in 
coprocessor 200 reads this buffered sound data from main memory 300 and converts it into electrical audio signals 
30 (stereo, left and right) for application to and reproduction by television 58. 

More specifically, main processor 100 reads a video game program 108 stored in main memory 300. In response 
to executing this video game program 108, main processor 100 creates a list of commands for coprocessor 200. This 
command list, in general, includes two kinds of commands: graphics commands and audio commands. Graphics com- 
mands control the images coprocessor 200 generates on TV set 58. Audiocommands specifying the sound coprocessor 
35 200 causes to be reproduced on TV loudspeakers 62. The list of graphics commands may be called a "display list 0 
because it controls the images coprocessor 200 displays on the TV screen 60. A list of audio commands may be called 
a "play list" because it controls the sounds that are played over loudspeaker 62. Generally, main processor 1 00 specifies 
both a display list and a play list for each "frame" of color television set 58 video. 

In this example, main processor 100 provides its display/play list 110 to coprocessor 200 by copying it into main 
40 memory 300. Main processor 100 also arranges for the main memory 300 to contain a graphics and audio database 
that includes all that the data coprocessor 200 needs to generate graphics and audio requested in the display/play list 
110. For example, main processor 100 may copy the appropriate graphics and audio data from storage device read 
only memory 76 into the graphics and audio database within main memory 300. Main processor 100 tells coprocessor 
200 where to find the display/play list 1 1 0 it has written into main memory 300, and that display/play list 1 10 may specify 
45 which portions of graphics and audio database 112 the coprocessor 200 should use. 

The coprocessor's signal processor reads the display/play list 110 from main memory 100 and processes this list 
(accessing additional data within the graphics and audio database as needed). The signal processor generates two 
main outputs: graphics display commands for further processing by display processor; and audio output data for tem- 
porary storage within main memory 300. Once signal processor 400 writes the audio output data into main memory 
50 300, another part of the coprocessor 200 called an "audio interface" (not shown) reads this audio data and outputs it 
for reproduction by television loudspeaker 62. 

The signal processor can provide the graphics display commands directly to display processor over a path internal 
to coprocessor 200, or it may write those graphics display commands into main memory 300 for retrieval from the main 
memory by the display processor. These graphics display commands command display processor to draw ("render") 
55 specified geometric images on television screen 60. For example, display processor can draw lines, triangles or rec- 
tangles based on these graphics display commands, and may fill triangles and rectangles with particular textures (e. 
g., images of leaves of a tree or bricks of a brick wall such as shown in the exemplary screen displays in Figures 6A 
through F) stored within main memory 300 - all as specified by the graphics display command. It is also possible for 
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main processor 1 00 to write graphics display commands directly into main memory 300 so as to directly command the 
display processor. The coprocessor display processor generates, as output, a digitized representation ol the image 
that is to appear on television screen 60. 

This digitized image, sometimes called a "bit map," is stored (along with "depth or Z" information) within a frame 
s buffer residing in main memory 300 of each video frame displayed by color television set 58. Another part of coprocessor 
200 called the "video interface" (not shown) reads the frame buffer and converts its contents into video signals for 
application to color television set 58. 

Each of Figures 6A-6F was generated using a three-dimensional model of a "world" that represents a castle on a 
hilltop. This model is made up of geometric shapes (i.e., lines, triangles, rectangles) and "textures" (digitally stored 
10 pictures) that are "mapped" onto the surfaces defined by the geometric shapes.. System 50 sizes, rotates and moves 
these geometric shapes appropriately, "projects" them, and puts them all together to provide a realistic image of the 
three-dimensional world from any arbitrary viewpoint. System 50 can do this interactively in real time response to a 
person's operation of game controllers 86. 

Figures 6A-6C and 6F show aerial views of the castle from four different viewpoints. Notice that each of the views 
is is in perspective. System 50 can generate these views (and views in between) interactively with little or no discernible 
delay so it appears as if the video game player is actually flying over the castle. 

Figures 6D and 6E show views from the ground looking up at or near the castle main gate. System 50 can generate 
these views interactively in real time response to game controller inputs commanding the viewpoint to "land" in front 
of the castle, and commanding the "virtual viewer" (i.e., the imaginary person moving through the 3-D world through 
20 whose eyes the scenes are displayed) to face in different directions. Figure 6D shows an example of "texture mapping" 
in which a texture (picture) of a brick wail is mapped onto the castle walls to create a very realistic image. 

Figure 4A and 4B comprise an exemplary more detailed implementation of the Figure 2 block diagram. Components 
in Figures 4A and 4B, which are identical to those represented in Figure 2, are associated with identical numerical 
labels. Many of the components shown in Figures 4A and 4B have already been described in conjunction with Figure 
2S 2 and further discussion of these components is not necessary. 

Figures 4A and 4B show the interface between system components and the specific signals received on device 
pins in greater detail than shown in Figure 2. To the extent that voltage levels are indicated in Figures 4A and 4B, VDD 
represents +3.3 volts and VCC represents +5 volts. 

Focusing first on peripheral interface 138 in Figure 4B, signals such as CLDRES, NMI, RESIC, CLDCAP and 
30 RSWIN have been previously explained in conjunction with Figures 2, 3A and 3B which explanation will not be repeated 
herein. Three coprocessor 200/peripheral interface 138 communication signals are shown: PCHCLK, PCHCMD, and 
PCHRSP. These signals are transmitted on 3 bit wide peripheral interface channel bus as shown in Figures 2, 4A and 
4B. The clock signal PCHCLK is used for timing purposes to trigger sampling of peripheral interface data and com- 
mands. The clock signal is transmitted from the coprocessor 200 to the peripheral interface 1 38. 
35 Coprocessor 200 and CPU 100, based on the video game program store in storage device 54, supply commands 

for the peripheral interface 138 to perform on the PCHCMD control line. The command includes a start bit field, a 
command code field and data or other information. 

The peripheral interface circuitry (as will be described further below) decodes the command and, if the data is 
ready in response to the command, sends a PCHRSP response signal comprising an acknowledge signal "ACK" fol- 
40 lowed by the response data. Approximately two clock pulses after the peripheral interface 1 38 generates the acknowl- 
edgment signal ACK, data transmission begins. Data received from the peripheral interface 138 may be information/ 
instructions stored in the boot ROM or controller status or controller data, etc. 

Figure 5A shows representative signals transmitted across the PCHCLK, PCHCMD and PCHRSP lines. The re- 
lationships between the clock signal and the peripheral interface sampling of the PCHCMD line and the clock signal 
45 and the peripheral interface outputting of the response is shown in Figure 5A. Additionally, the relationships between 
the clock signal and coprocessor 200 (RCP) outputting a PCHCMD and the coprocessor sampling the PCHRSP is 
shown in Figure 5A. As suggested by Figure 5A, the high and low levels of the clock signal may have different pulse 
widths dependent upon whether the system is to be utilized with NTSC or PAL. Figure 5B shows exemplary signals 
appearing on the peripheral interface channel for four exemplary commands serving to read 4 bytes into memory, write 
so 4 bytes into memory, execute a peripheral interface macro instruction or write 64 bytes into peripheral interface buffer 
memory. Further explanation of the peripheral interface device and these commands will be described in detail below 
Turning back to the Figure 4B peripheral interface 1 38, SECCLK, SECTRC and SECTRD are three security related 
signals coupled between two security processors embodied within the peripheral interface 138 and game cartridge, 
respectively. SECCLK is a clock signal used to clock security processor operations in both the peripheral interface and 
55 the game cartridge. SECTRC is a signal sent from the peripheral interface 1 38 to the game cartridge defining a data 
transmission clock signal window in which data is valid and SECTRD is a data transmission bus signal in which data 
from the peripheral interface 1 38 and data from the game cartridge security processor are exchanged at times identified 
by the SECTRD transmission clock pulses. Finally, the peripheral interface 138 includes a pin RSWIN which is the 
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reset switch input pin. 

Turning next to connector 1 54, as previously mentioned, the system 50 includes an expansion capability for adding 
another controller 56. Data from such a controller would be transmitted via the EXT JOY I/O pin of the connector 154. 
The three above-mentioned security related signals are coupled between the game cartridge security processor and 
5 peripheral interface processor at the pins labeled SECTRD, SECTRC and SECCLK. 

The cartridge connector additionally couples a cold reset signal CRESET to the game cartridge security processor 
to enable a power on reset function. Additionally, if during processor authentication checking, if, for example, the pe- 
ripheral interface processor does not receive data which matches what is expected, the cartridge processor may be 
placed in a reset state via the CRESET control pin. 
10 The NMI input is a control pin for coupling an NMI interrupt signal to the cartridge. The control line CARTINT is 
provided to permit an interrupt signal to be generated from the cartridge to CPU 100 to, for example, if devices are 
coupled to the cartridge requiring service by CPU 100. By way of example only, a bulk storage device such as a CD 
ROM is one possible device requiring CPU interrupt service. 

As shown in Figure 4B, the system bus is coupled to the cartridge connector 1 54 to permit accessing of program 
is instructions and data from the game cartridge ROM and/or bulk storage devices such as CD ROM, etc. In contrast 
with prior video game systems such as the Nintendo NES and SNES, address and data signals are not separately 
coupled on different buses to the game cartridge but rather are multiplexed on an address/data 16 bit wide bus. Read 
and write control signals and address latch enable high and low signals, ALEH and ALEL, respectively are also coupled 
to the game cartridge. The state of the ALEH and ALEL signals defines the significance of the information transmitted 
20 on the 16 bit bus. The read signal RD is a read strobe signal enabling data to be read from the mask ROM or RAM in 
the game cartridge. The write signal WR is a strobe signal enabling the writing of data from the coprocessor 200 to 
the cartridge static RAM or bulk media device. The multiplexed use of the 16 bit address/data bus is described in further 
detail in conjunction with Figures 12-14 in describing external memory accessing. 

Sound may be output from the cartridge and/or through connector 154 to the audio mixer 142 channel 1 and 
25 channel 2 inputs, CH1 EXT and CH2EXT, respectively. The external sound inputs from SOUNDL and SOUNDR will be 
mixed with the sound output from the coprocessor via the audio DAC 140 and the CH1 IN, CH2IN inputs to thereafter 
output the combined sound signal via the audio mixer outputs CH10UT, CH20UT which are, in turn, coupled to the 
AUDIOL and AUDIOR inputs of the audio video output connector 149 and thereafter coup led to the TV speakers 62a,b. 
The connector 154 also receives a composite sync signal CSYNC which is the output of video DAC 144 which is 
30 likewise coupled to the audio video output connector 1 49. The composite sync signal CSYNC, as previously described, 
is utilized as a synchronization signal for use in synchronizing, for example, a light pen or photogun. 

The cartridge connector also includes pins for receiving power supply and ground signals as shown in Figures 4B. 
The +3.3 volts drives, for example, the 16 bit AD bus as well as other cartridge devices. The 12 volt power supply 
connection is utilized for driving bulk media devices. 
35 Turning to coprocessor 200 in Figure 4A, many of the signals received or transmitted by coprocessor 200 have 
already been described, which will not be repeated herein. The coprocessor 200 outputs an audio signal indicating 
whether audio data is for the left or right channel, i.e., AUDLRCLK. Serial audio data is output on a AUDDATA pin. 
Timing for the serially transmitted data is provided at the AUDCLK pin. Coprocessor 200 outputs seven video signals 
SRGBO through SRGB7 which synchronized RGB digital signals are coupled to video DAC 144 for conversion to 
40 analog. Coprocessor 200 generates a timing signal SYNC that controls the timing for the SRGB data which is coupled 
to the TSYNC input of video DAC 144. Coprocessor 200 receives a video clock input from clock generator 1 36 via the 
VCLK input pin for controlling the SRGB signal timing. The coprocessor 200 and CPU 100 use a P VALID SIGNAL to 
indicate that the processor 100 is driving a valid command or data identifier or valid address/data on the system bus 
and an E VALI D signal to indicate that the coprocessor 200 is driving a valid command or data identifier or valid address/ 
45 data on the system bus. Coprocessor 200 supplies CPU' 1 00 with master clock pulses for timing operations within the 
CPU 100. Coprocessor 200 and CPU 100 additionally use an EOK signal for indicating that the coprocessor 200 is 
capable of accepting a processor 100 command. 

Turning to main memory RDRAM 300 : 302, as depicted in Figure 4A, two RDRAM chips 300a and 300b are shown 
with an expansion RDRAM module 302. As previously described, the main memory RDRAM may be expanded by 
so plugging in a memory module into a memory expansion port in the video console housing. Each RDRAM module 300a, 
b, 302 is coupled to coprocessor 200 in the same manner Upon power-up RDRAM 1 (300a) is first initialized, then 
RDRAM2 (300b) and RDRAM3 (302) are initialized. RDRAM 1 is recognized by coprocessor 200 since its SIN input 
is tied to VDD, as shown in Figure 4A. When RD1 is initialized under software control SOUT will be at a high level. 
The SOUT high level signal is coupled to SIN of RDRAM 2 (300b) which operates to initialize RDRAM2. SOUT will 
55 then go to a high level which operates to initialize RDRAM3 (302) (if present in the system). 

Each of the RDRAM modules receives bus control and bus enable signals from coprocessor 200. The coprocessor 
200 outputs a TXCLK signal when data is to be output to one of RDRAM1 through 3 and a clock signal RXCLK is 
output when data is to be read out from one of the RDRAM banks The serial in (SIN) and serial out (SOUT) pins are 
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used during initialization, as previously described. RDRAM receives dock signals from the clock generator 136 output 
pin FSO. 

Clock generator 1 36 is a three frequency clock signal generator. By way of example, the oscillator within clock 
generator 136 may be a phase-locked locked loop based oscillator which generates an FSO signal of approximately 
s 250MHz. The oscillator also outputs a divided version of the FSO signal, e.g., FSO/5 which may be at approximately 
50 MHz, which is used for timing operations involving the coprocessor 200 and video DAC 144, as is indicated in 
Figures 4A and 4B. The FSC signal is utilized for timing the video encoder carrier signal. Clock generator 136 also 
includes a frequency select input in which frequencies may be selected depending upon whether an NTSC or PAL 
version of the described exemplary embodiment is used. Although the FSEL select signal is contemplated to be utilized 
10 for configuring the oscillator for NTSC or PAL use, as shown in Figure 4A, the input resets the oscillator under power- 
on reset conditions. When connected to the power on reset, the oscillator reset is released when a predetermined 
threshold voltage is reached. 

Figure 7 is a block diagram of peripheral interface 138 shown in Figure 2. The portion of peripheral interface 138 
previously described in conjunction with Figures 3A and 3B is not shown in Figure 7. Peripheral interface 1 38 is utilized 
is for I/O processing, e.g., controlling the game controller 56 input/output processing, and for performing game authen- 
ticating security checks continuously during game play. Additionally, peripheral interface 1 38 is utilized during the game 
cartridge/coprocessor 200 communication protocol using instructions stored in boot ROM 262 to enable initial game 
play. Peripheral interface 138 includes CPU 250, which may, for example, be a 4 bit microprocessor of the type man- 
ufactured by Sharp Corporation. CPU 250 executes its security program out of program ROM 252. As previously 
20 described, the peripheral interface processor 250 communicates with the security processor 152 embodied on the 
game cartridge utilizing the SECTRC, SECTRD and SECCLK signals. Peripheral interface port 254 includes two 1 bit 
registers for temporarily storing the SECTRC and SECTRD signals. 

Overall system security for authenticating game software is controlled by the interaction of main processor 100, 
peripheral interface processor 250, boot ROM 262 and cartridge security processor 152. Boot ROM 262 stores a set 
2S of instructions executed by processor 100 shortly after power is turned on (and, if desired, upon the depression of reset 
switch 90). The boot ROM program includes instructions for initializing the CPU 1 00 and coprocessor 200 via a set of 
initial program loading instructions (IPL). Authentication calculations are thereafter performed by the main processor 
100 and the result is returned to the CPU 250 in peripheral interface 138 for verification. If there is verification, the 
game program is transferred to the RDRAM, after it has been initialized, and a further authentication check is made. 
30 Upon verification of an authentic game program, control jumps to the game program in RDRAM for execution. Contin- 
uous authentication calculations continue during game play by the authenticating processor in the peripheral interface 
1 38 and by security processor 152 such as is described, for example, in U.S. Patent 4 : 799,635 and related U.S. Patent 
5,426,762 which patents are incorporated by reference herein. 

Turning back to Figure 7, a PCHCLK clock signal having a frequency of, for example, approximately 15MHz is 
35 input to clock generator 256 which, in turn, supplies an approximately 1MHz clocking signal to CPU 250 and an ap- 
proximately 1 MHz clock signal along the line SECCLK for transmission to the game cartridge security processor 1 52. 
PIF channel interface 260 responds to PCHCLK and PCHCMD control signals to permit access of the boot ROM 262 
and RAM 264 and to generate signals for controlling the interruption of CPU 250, when appropriate. 

Figure 8 is a block diagram of the PIF channel interface 260 shown in Figure 7. As shown in Figure 8, commands 
40 are serially loaded into shift register 282 on line PCHCMD under the control of clock pulses PCHCLK. Shift register 
282 operates as a serial to parallel converter and a parallel to serial converter as explained below. Controller 284 
decodes commands which are output in parallel from shift register 282 to, for example, generate read or write control 
signals for accessing information from RAM 264, reading instructions out of boot ROM 262 or to generate interrupt 
control signals to be communicated to CPU 250 and/or generates other conventional control signals (CTL) as needed. 
45 information accessed from RAM 264 and instructions accessed from boot ROM 262 are loaded via internal bus 285 
in parallel to shift register 282 and then are clocked out of shift register 282 serially on the response line PCHRSP. If 
the command loaded into shift register 282 is a write to RAM 264 command, controller 284 will decode the command, 
generate a write control signal and output data associated with the command in parallel from the shift register to RAM 
264. Thus, controller 284 exercises DMA control in controlling accessing of RAM 264 and boot ROM 262 data, and 
50 loading such data in shift register 282 and in controlling data transfer from shift register 282 to RAM 264. PIF channel 
interface 260 also includes a buffer control/status register 283 for storing channel status and/or control bits which may 
be accessed by controller 284 or CPU 250. This register stores information indicative of current buffer 264 access size 
and buffer 264 read/write status. 

As shown in Figure 5A, the PCHCLK signal is the basic clock signal which may, for example, be a 15.2 MHz signal 
55 utilized for clocking communication operations between the coprocessor 200 and the peripheral interface 1 38. Figure 
5A also shows the timing for the PCHCMD command issued by the coprocessor 200 to the peripheral interface 138. 
The command is utilized for reading and writing from and to RAM 264-and for reading from boot ROM 262. The pe- 
ripheral interface 1 38 in turn provides a PCHRSP response which includes both accessed data and an acknowledgment 
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signal. The lower three timing signals shown in Figure 5A are signals from the perspective of the peripheral interface 
(PIF) whereas the upper three timing signals are from the perspective of the coprocessor. 

In the present exemplary embodiment, four commands are contemplated including a read 4 byte from memory 
command for reading from RAM 264 and boot ROM 262, a write 4 byte memory command for writing to RAM 264, a 

s PIF macro command for reading 64 bytes from buffer 264 and accessing control/data from the player controller (here- 
inafter JoyChannel). The CPU 250 is triggered to send or receive JoyChannel data by the PIF macro instruction. The 
main processor 100 may thus generate a PIF macro command which will initiate VO processing operations by CPU 
250 to lessen the processing burden on main processor 100. The main processor 100 may also issue a write 64 byte 
buffer command which writes 64 bytes into RAM 264. 

10 Turning back to Figure 7, peripheral interface 138 also includes a bus arbitrator 258 which allocates access to 

RAM 264 between CPU 250 and PIF channel interface 260. RAM 264 operates as a working RAM for CPU 250 and 
stores cartridge authenticating related calculations. RAM 264 additionally stores status data such as, for example, 
indicating whether the reset switch has been depressed. RAM 264 also stores controller related information in, for 
example, a 64 byte buffer within RAM 264. Figure 5B shows exemplary command formats for reading and writing from 

is and to the 64 byte buffer. 

Both the buffer RAM 264 and the boot ROM 262 are in the address space of main processor 100. The CPU 250 
of the peripheral interface 138 also can access buffer RAM 264 in its address space. Memory protection techniques 
are utilized in order to prevent inappropriate access to portions of RAM 264 which are used for authenticating calcu- 
lations. 

20 As can be seen in Figure 7, the reset and interrupt related signals shown in Figures 3A and 3B, such as CLDRES, 

CLDCAP and RESIC are generated and/or processed as explained above. The signal RSWIN is coupled to port 268 
upon the depression of reset switch 90 and, as explained above, the NMI and the pre-NMI warning signal, INT2, are 
generated as previously described in conjunction with Figure 3B. 

Port 268 includes a reset control register storing bits indicating whether an NMI or INT2 signal is to be generated. 

25 A third bit in the reset control register indicates whether the reset switch 90 has been depressed. 

As mentioned previously, peripheral interface 138 : in addition to its other functions, serves to provide input/output 
processing for two or more player controllers. As shown in Figure 1 , an exemplary embodiment of the present invention 
includes four sockets 80a-d to accept up to four peripheral devices. Additionally the present invention provides for 
including one or more additional peripheral devices. See connector 154 and pin EXT JOY I/O. The 64 byte main proc- 

30 essor 1 00 does not directly control peripheral devices such as joystick or cross-switch based controllers. Instead, main 
processor 1 00 controls the player controllers indirectly by sending commands via coprocessor 200 to peripheral inter- 
face 1 38 which handles I/O processing for the main processor 1 00. As shown in Figure 7, peripheral interface 1 38 also 
receives inputs from, for example, five player controller channels via channel selector 280, demodulator 278, joystick 
channel controller 272 and port 266. Joystick channel data may be transmitted to peripheral devices via port 266 to 

35 joystick channel controller 272, modulator 274 and channel select 276. 

With respect to JoyChannel communication protocol, there is a command protocol and a response protocol. After 
a command frame, there is a completion signal generated. A response frame always comes after a command frame. 
In a response frame, there is a completion signal generated after the response is complete. Data is also sent from the 
peripheral interface 1 38 to the JoyChannel controllers. The CPU 250 of the peripheral interface controls such commu- 

40 nications. 

Each channel coupled to a player controller is a serial bilateral bus which may be selected via the channel selector 
276 to couple information to one of the peripheral devices under the control of the four bit CPU 250. If the main processor 
100 wants to read or write data from or to player controllers or other peripheral devices, it has to access RAM 264. 
There are several modes for accessing RAM 264 as shown in Figure 5B. The 64 bit CPU 100 may execute a 32 bit 

45 word read or write instruction from or to the peripheral interface RAM 264. Alternatively, the CPU may execute a write 
64 byte DMA instruction. This instruction is performed by first writing a DMA starting address into the main RAM address 
register. Thereafter, a buffer RAM 264 address code is written into a predetermined register to trigger a 64 byte DMA 
write operation to transfer data from a main RAM address register to a fixed destination address in RAM 264. 

A PIF macro also may be executed. A PIF macro involves an exchange of data between the peripheral interface 

50 RAM 264 and the peripheral devices and the reading of 64 bytes by DMA. By using the PIF macro, any peripheral 
device's status may be determined. The macro is initiated by first setting the peripheral interface 138 to assign each 
peripheral device by using a write 64 byte DMA operation or a write 4 byte operation (which could be skipped if done 
before and no change in assignment is needed). Thereafter, the DMA destination address is written onto a main RAM 
address register and a predetermined RAM 264 address code is written in a PIF macro register located in the coproc- 

55 essor which triggers the PIF macro. The PIF macro involves two phases where first, the peripheral interface 1 38 starts 
a reading or writing transaction with each peripheral device at each assigned mode which results in updated information 
being stored in the peripheral interface RAM 264. Thereafter, a read 64 byte DMA operation is performed for transferring 
64 bytes from the fixed DMA starting address of the RAM 264 to the main RAM address register programmable DMA 
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destination address within main RAM 300. See Figure 5B for PIF macro timing signals. 

The table below exemplifies the manner in which the 64 bit main processor 100 communicates using its memory 
address space by addressing RAM 264 to exchange information with the JoyChannels. 
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There are six JoyChannels available in the present exemplary embodiment. Each Channel's transmit data and 
receive data byte sizes are all independently assignable by setting size parameters. In the exemplary embodiment, all 
six channels size parameter setups are required, whether they are used or not. As shown above, RAM 264 is to be 
used for each channel's TxData/RxData assignment. 

TxData/RxData assignment becomes effective when main processor 100 sets a format flag (0x1 FC007FC bO) by using 
Wr64B or Wr4B. 

In the exemplary embodiment, if processor 100 writes "0x00", "OxFD", "OxFE" or "OxFF" as TxData Size, the data 
is not recognized as TxData size but has a special function as indicated below. They become effective when processor 
100 sets format bit (Ox1FC007FC bO) by using Wr64B or Wr4B. 

"0x00" = Channel Skip 

If 0x00 is written as TxData Size, respective JoyChannel transaction is not executed. 
"OxFD'' = Channel Reset 

If OxFD is written as TxData Size, PIF outputs reset signal to respective JoyChannel. 
"OxFE" = Format End 

If OxFE is written as TxData Size, TxData/RxData assignment is end at this ")xFE". In other words, the TxData 
Size or RxData Size after "OxFE" is ignored 
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B OxFF B = Dummy Data 

TxData Size's OxFF is used as the dummy data for word aligning the data area. 

Each Channel has four flags. Two of them have information from processor 100 to JoyChannel and others from 
s JoyChannel to processor 1 00. 

Skip = Channel Skip 

If processor 1 00 sets this flag to T : respective JoyChannel transaction is not executed. This flag becomes effective 
without formal flag. 

10 

Res = Channel Reset 

If 64 bit CPU set this flag to "1", PIF outputs reset signal to respective JoyChannel. This flag becomes effective 
without format flag. 

is NR = No Response to JoyChannel 

When each JoyChannel's peripheral device does not respond, the respective NR bit is set to "1". This is the way 
to detect the number of currently connected peripheral devices. 

Err = JoyChannel Error 

20 when communication error has occurred between PIF and peripheral device, Err flag is set to "1 M . 

tf the 64 bit CPU 100 wants to change JoyChannel's Tx/RxData assignment, a 32 bit format flag is used, where a 
certain bit(s) specify the desired format. For example, when Wr64B or WY4B is issued when this flag is " 1 PIF executes 
each JoyChannel's Tx/RxData assignment based on each channel's Tx/Rx Size. In other words, unless this flag is set 
25 to "1" with Wr64B or Wr4B, Tx/RxData area assignment does not change. After Tx/RxData assignment, this flag is 
reset to "O" automatically. 

Figure 9A is a block diagram of the joystick channel controller 272 and port 266 shown in Figure 7. As indicated 
in Figure 9A, bus 287 which is coupled to CPU 250 couples data to be transmitted to JoyChannel through port register 
290 to FIFO buffer 31 2. Under the control of controller 31 0, four bit data is then loaded into shift register 31 4 in parallel 

30 and serially clocked out to modulator 274 into an identified JoyChannel selected by channel select 276 based on an 
address resident in address register RA299. Data received from a JoyChannel is input via channel selector 280 to 
demodulator 278 and then is serially loaded into shift register 314. The serial data is converted to parallel by shift 
register 31 4, loaded into Fl FO 31 2 and then coupled to C PU 250 via register 292. Controller 31 0 generates conventional 
control signals (CTL) used to control the data exchange described herein. 

35 The function of the various port 266 registers are summarized below. Register RO(290) is a JoyChannel output 

register for receiving data to be output via modulator 274 and channel select 276. Joystick Channel controller 272 uses 
a JoyChannel address register R A to control the channel select to identify particular JoyChannels for input and output 
of data. Register R1 292 is a four bit JoyChannel input data register. Register CR 294 is a JoyChannel control register 
which, for example, identifies whether data is being received or transmitted. Register SR 296 is a JoyChannel status 

40 register which, for example, includes a bit indicating that a Joy Bus data register is ready and that a bit indicating that 
a Joy Bus error has been detected. Register ER 298 is a Joy Bus error register that indicates whether there has been 
a collision error, frame error, overrun error or no response error. With respect to the no response signal, even if a 
controller is not connected and therefore could not give a response, the lack of response is treated as an error signal 
in the exemplary embodiment of the present invention. 

45 As can be seen in Figure 9A, controller 310 supplies the status register and the error register with the status and 

error information identified above in parallel and receives control signals from control register 294 for controlling buffer 
312 and shift register 314 to respond according to the current mode of operation. 

The video game system is programmed to allow one to four players to play at the same time by, for example, 
setting up RDRAM 300 as shown below: 

so 
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PlfRAM Format Flag On 



Ox 01 



OxOl 



0x01 



0x01 



Addr. +3 

Ch. 1 -4 
Read Controller 
Data Command 
OxOl 



Ch.4 



Ch.3 



Ch.2 



Ch. 1 



Thereafter, the DMA start address is written in a RDRAM coprocessor 200 address register. A RAM 264 address 
code is then written into the write 64 byte register in the coprocessor 200 and a write DMA destination address is written 
in the RDRAM address register in the coprocessor. Thereafter, the address in the 64 byte RAM 264 is written in the 
PIF macro register in the coprocessor. 

The controllers response is returned to RDRAM. If only two controllers are connected to channel 1 and channel 
2, DMA destination RAM area resulting therefrom after the PIF macro is executed is preferably as shown below. How- 
ever, if a controller is connected to channel 3 or channel 4, the channel's RAM area changes to the same as channel 
1 or channel 2. 
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10 



15 



20 



25 



30 



35 



40 



45 



50 



PIfRAM Format Flag is Reset to ^0" 



Addr. +60 



Ch. 5 



0x00 
Channel Skip, 



OxFF 



OxFF 



BAG ST 1 1 — 



Addr. +S 

Addr. +4 

DMA Destination 
Addr. 



OxFF 



BAG ST T 1 — 



OxFF 



Ch.6 



0x00 
Channel Skip 



T 



No Response from JoyChannel 



0x01 



0x84 



No Response from JovChartnel 



0x01 



OOLREDCF 



0x01 



OOLREDCF 



0x01 



0x84 
No Response 



Joystick X Pole 



0x04 



Joystick X Pole 



0x04 



0x00 



0x01 



3 



0x01 



Joystick Y Pole 



I 



0x01 



Joystick Y Pole 



0x01 



Addr.+O 



Addr. +1 



Addr. +2 



Addr. +3 



Ch.4 



Ch. 3 



Ch.2 



Ch. 1 



The peripheral device channel is designed to accept various types of future peripheral devices. The present ex- 
emplary embodiment uses an extensible command which is to be interpreted by peripherals including future devices. 
The commands occupy the first byte of a TxData area in RAM 264. Many bits and commands are reserved for future 
extension. Exemplary commands relating to peripheral devices are shown below. Commands are also provided for 
read and writing data to a memory card. Backup data for a game may be stored on a memory card. In this fashion, no 
backup battery need be used for this memory during game play since it plugs into the controller. Certain of these 
commands contemplate an expansion memory card module 313 that plugs into a player controller 56 as is shown in 
Figure 11 . For further details relating to exemplary controllers that may be used in system 50 and the communications 
protocol between such controller and the peripheral interface 1 38 (and processing associated therewith) reference is 
made to Japanese patent application no. 00534 filed October 9, 1995 naming Nishiumi et al as inventors, which ap- 
plication is incorporated herein by reference. Exemplary controller commands are shown below. 
Command 0: Ask each peripheral device's type and status flag 
TxSize: 1 byte RxSize: 3 byte 

This command is used to ask the peripheral device's type and status flags, and its answer is supposed to be 
returned into RX data area. 
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b7 


b6 


b5 


b4 


b3 | b2 


bl 


bO 


TxDala 


I BYTE 




RxData 


I BYTE 


Type L * 


2 BYTE 


« Type H ► 


3 BYTE 


« Status Flag ► 



Peripheral Device's Type 

This type is provided from the connected peripheral device about its functions and features as shown for example 
below. 
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bl 
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bO 
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Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


L 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


With 


Reserved 


Joystick ABS Count. 














JoyPort 




Standard 



L bO: In the case of the standard controllers, they would send a "1 " response which indicates that controllers contain 
counters and send the joystick data as the absolute value. 

L b2: In the case of the standard controllers, they would send a "1 " response which indicates that controllers have 
the JoyPort which connects to the exchangeable memory card shown in Figure 11 . 

Status Flags 

These status flags are the response from the connected peripheral device about its status. In the case of standard 
controllers, these flags are used for memory card. 



b7 


b6 


b5 


b4 


b3 


b2 


bl 


bO 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


ADDR CRC report 


Card Xchg 


Card ON 



bO: If memory card is connected to controller, this flag is set to "1". If not, this flag is set to "0". 

b1 : After a controller is plugged in, if memory card is pulled out, this flag is set to "1 ". This flag is reset to "0" when 
controller plugged and power supplied, or command 0 or 255 (controller software reset command) issued with 
memory card connected. If controller is plugged and power supplied without memory card, this flag is indefinite. 

b2: AddrCRC (cyclic redundancy code) report is sent from the controller in communicating with JoyPort. This flag 
status "1 " means that Address H/L are not transferred to the controller correctly This flag is reset to "0", when 
peripheral device plugged and power supplied or command 0 or 255 issued. 

Command t : Read Controller Data 

TxSize: 1 byte RxSize: 4 byte 

Command 1 is used for getting controller's button condition and Joystick condition. Joystick's counter is reset to 
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"0x00" when controller is plugged in and power is supplied, command 0 or 255 issued, JoyChannel reset issued or L, 
R, START buttons pushed at the same time. JRRes bit shows that L, R, START buttons are pushed at the same time. 
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bl 
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i 
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3 BYTE 


„ Joystick X axis counter readings + 


4 BYTE 


* Joystick Y axis counter readings * 
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Turning back to Figure 7, the JoyChannels do not require two separate lines for clock and data signals, respectively. 
Instead, JoyChannel data is transmitted to represent Vs and O's as shown in Figure 9B. In this fashion, only power 
line, ground and data transmitted as shown in Figure 9B are required. Thus, as shown in Figure 9B, pulse duty mod- 

20 ulation is utilized to represent 1's and O's. By sampling the data at the middle of the clocking signal whether the data 
represents a 1 or 0 is determined. 

The flow charts in Figures 10A through 10C depict the sequence of operations involved in sending and receiving 
data between port 266 shown in Figure 9A and the JoyChannels shown in Figure 7. A routine for sending and receiving 
data is shown in which the channel mode is set (31 5). A send counter is set to the desired value (317). A check is then 

25 made, as indicated at block 31 9, to determine if the send counter is equal to zero. 

If the send counter is equal to zero, then the port is set to receive mode (321). Thereafter, the receive counter is 
set (323). A check is then made to determine if the receive counter is zero (325). If the receive counter is zero, then 
the port is set to send mode (327), after which return is made to the calling routine being executed by CPU 250. 
If, at block 319, a determination was made that the send counter is not equal to zero, then the routine branches 

30 to a send-a-byte of data sub-routine (331). As indicated in Figure 10B, in accordance with the send-a-byte of data 
routine, a check is made to determine whether the port ready flag is on (338). If the port ready flag is not on, the routine 
cycles until the port ready flag is on. When the port ready flag is on, then a byte of data is sent from memory to the 
port (339) and the routine branches to the calling routine in block 331 in Figure 1 0A. After a byte of data has been sent, 
the send counter is decremented (333) and the routine branches back to block 31 9. Once the send counter is equal 

35 to zero, the receive mode is entered as previously described. 

If the check at block 325 indicates that the receive counter is not equal to zero, then the routine branches to a 
reC eive-a-byte of data subroutine (335) shown in Figure 10C. In accordance with the receive-a-byte of data routine 
(335), a check is made to determine whether the port ready flag is on (341 ). If the port ready flag is not on, then the 
routine cycles until the port ready flag is turned on. Thereafter, a byte of data from the port is sent to the memory (342) 

40 and the routine branches to the calling routine (343) at block 335. After a byte of data has been received, the receive 
counter is decremented (337) and the routine branches back to block 325. 

Figure 12 is a block diagram which demonstrates in detail how the address/data 16 bit bus is utilized to read 
information from a game cartridge ROM and read and write information from a game cartridge RAM. Coprocessor 200 
generates an address latch enable high signal which is input to the ALEH pin in Figure 1 2. Exemplary timing signals 

45 for the reading and writing of information are shown in Figures 1 3 and 14 respectively The coprocessor 200 similarly 
generates an address latch enable flow signal (shown in Figure 13) which is coupled to the ALEL pin which, in turn, 
enables information on address pin 0 to 1 5 to be loaded into the input butler 352. Bits 7 and 8 and 1 1 and 1 2 from input 
buffer 352 are, in turn, coupled to address decoder 356. In Ihe exemplary embodiment of the present invention, bits 
7, 8 and 11, 1 2 are decoded by the address decoder to ensure that they correspond to 4 bits indicative of the proper 

so location in the address space for the mask ROM 368. Thus, the mask ROM 368 has a designated location in the AD1 6 
bus memory map and decoder 356 ensures that the mask ROM addressing signals correspond to the proper mask 
ROM location in this memory map. Upon detecting such correspondence, decoder 356 outputs a signal to one-bit chip 
select register 360. Turning to Figure 1 3, when ALEH transitions from high to low, as shown in Figure 12, bits 0 to 6 
output from input buffer 352 are latched into 7 bit address register 362. Simultaneously, data from address decoder 

55 356 is latched into chip select register 360 and register 358 is also enabled, as indicated in Figure 12. 

When the coprocessor 200 outputs low order address bits on the AD1 6 bus, the address signals are input to input 
buffer 352. The bits are coupled in multiple directions. As indicated in Figure 12, bits 1 to 8 are set in an 8 bit address 
presettable counter 366 and bits 9 to 1 5 are coupled to 7 bit address register 364. At a time controlled by ALEL (shown 
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in Figure 13), when registers 358 and 360 are set and registers 362, 364 and 366 are loaded, the read out of data is 
ready to be initiated. As indicated in Figure 13, the time TL is required for data to be output after the ALEL signal 
transitions from high to low. After the ALEL signal has been generated, a read pulse RD is applied on the pin shown 
in the top lefthand portion of Figure 12. The read signal is input to gate 374 whose other input is coupled to gate 372. 

5 When the output of registers 358, 360 and signals ALEL and ALEH are low, then the output of 372 will be low. When 
RD and the output of 372 are low, the clock signal is generated at the output of 374 thereby causing the counter 366 
to be clocked and begin counting and the output buffer 354 to be enabled. The 8 bit address presettable counter 
determines the memory cell array column selected and the combination of the output of address register 362 and 
address register 364 defines the memory cell row selected. The output data is temporarily stored in latch 370 and then 

10 coupled to output buffer 354. Thereafter, the data is transmitted back to coprocessor 200 via the same 1 6AD 0 to 1 5 
lines. 

By virtue of using the multiplexed AD 0 to 15 bus, the game cartridge pin out is advantageously reduced. 
The circuitry of Figure 1 2, although designed for accessing a mask ROM, is readily adaptable for writing information 
into, for example, static RAM using the timing signals shown in Figure 1 4. In a static RAM embodiment, the processing 

is of the ALEH and ALEL signals are the same as previously described as is the loading of information in the registers 
358, 360, 362, 364 and 366. A write signal, such as shown in Figure 14 is generated and coupled to gate 374 instead 
of the read signal shown in Figure 12. Data is output from coprocessor 200 for writing into a static RAM memory 368. 
The data is loaded into buffer 352. A clock pulse is generated at the output of gate 374 to cause the address presettable 
counter to begin counting to cause data to be written into memory 368 rather than read out as previously described. 

20 Tables 1 through 3 below show the signals used in Figure 12 and explain the timing symbols utilized in the read and 
write timing charts shown in Figures 1 3 and 1 4. The times indicated in Tables 2 and 3 are for purposes of illustration only. 



TABLE 1 



SIGNAL DESCRIPTION 


PIN NAME 


I/O 


DESCRIPTION 


ALEH 


O 


Latch Timing Clock for High Address 


ALEL 


O 


Latch Timing Clock for Low Address 


RD 


O 


Read Strobe 


WR 


O 


Write Strobe 


AD [0:15] 


I/O 


Address or Data Input/Output 



TABLE 2 



40 



WRITE Address Domain 1 


SYMBOL 


PARAMETER 


MIN. 


TYP. 


MAX. 


UNIT 


Wes 


ALEL Setup Time 


70 






ns 


Wed 


ALEL Delay Time 


70 






ns 


t A s 


Address Setup Time 


30 






ns 


*AH 


Address Hold Time 


0 






ns 


twCYC 


Write Cycle Time 


Variable depend on t P1 and t R1 


ns 


*DS 


Data Setup Time 


Variable depend on t P1 


ns 


twD 


Write Data Delay Time 




15 




ns 


*DH 


Data Hold Time 


0 






ns 


WlC 


Write Recovery Time 


20 






ns 


X ViSD 


Start Delay Time 


0 






ns 
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READ Address Domain 1 


SYMBOL 


PARAMETER 


MIN. 


TYR 


MAX. 


UNIT 


MLLO 


ALEL Setup Time 


70 






ns 


Iai en 


ALEL Delay Time 


70 






ns 


Mo 


Address Setup Time 


30 






ns 


An 


Address Hold Time 


0 






ns 


^RCYC 


Read Cycle Time 


Variable depend on t P1 and t R1 


ns 


^RD 


Read Access Time 


Variable depend on t P1 


ns 


^RS 


Read Setup Time 




15 




ns 


toH 


Output Hold Time 


0 






ns 


tDF 


Output Disable Time 






40 


ns 


tRRC 


Read Recovery Time 


0 






ns 


^RSD 


Start Delay Time 


0 






ns 



TABLE 3 



25 



PROGRAMMABLE PARAMETER (ADDRESS DOMAIN 1) 


Symbol 


Parameter 


Extent 


UNIT 


tu 


Latency Time 


16ns x 1 - 16ns 256 


ns 


tR 


Pulse Width 


16ns x 1 - 16ns x 256 


ns 


tm 


Release Time 


16ns x 1 - 16ns x 4 


ns 



As shown in Figure 2, the AD16 bus may be used to address devices other than ROM. For example, Figure 2 
shows a read/write RAM which may be accessed by the video game system 50 through connector 154. By way of 
example only, ROM may occupy address domain 1 in the processor 1 00 memory space. In accordance with the present 

3S invention, a memory device having a different address domain may have different timing parameters. Depending upon 
the detected address domain, e.g., 1 or 2, the AD 16 bus couples signals having different timing characteristics to 
connector 154. By detecting, for example, whether address domain 1 or 2 is being accessed, the coprocessor 200 
may select one of two sets of timing signals to couple to connected 1 54 and the AG 1 6 bus system. In this fashion, a 
game program can configure the video game system 50 to generate timing signals tailored to the memory media for 

40 which the game has been designed. Table 3 also shows an exemplary set of programmable parameters within a given 
address space, e.g., address domain 1 . The concurrently filed copending application incorporated herein by reference 
shows further details concerning the coprocessor registers involved in programming the AD 16 bus in accordance with 
address domain as described above. 

45 Further Security System Embodiments 

Example Manufacturing Process To Match A Security Microprocessor Chip With a Video Game Program 

Figure 15 shows an example process for manufacturing external storage units embodying security features. In 
so this example process, the manufacturing facility customizes security microprocessor chips 152 to match particular 
video game programs. This customization allows the video game system main unit 52 to confirm, each time a video 
game is played, that the video game is being supplied by an external storage unit 54 including a security microprocessor 
chip 152 that has been matched for use with that particular video game or game title. Such matched pairing between 
video game titles and security microprocessor chips 152 can, for example, make it more difficult for someone to use 
ss a security microprocessor chip 1 52 from one external storage unit 54 with any game or game title other than the one 
stored in that same external storage unjt. 

In this Figure 15 example, the facility that manufactures external storage unit 54 inserts a predetermined block 
500 of program instructions and/or data into the video game program 502. This block 500 of program instructions and/ 
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or data may, for example, be inserted into the video game program 502 beginning at a predetermined location within 
the video game program. The block 500 may have a predetermined size. 

In addition to inserting the block 500 into the video game program 502, the manufacturing facility uses a computation 
program 506 to transform or convert the block 500 into a corresponding authentication code ("A code") 508. Compu- 

5 tation program 506 is shown for illustration purposes as a calculator, but preferably comprises a computer program 
performed using a general purpose computer such as a personal computer or any other computing device. 

The transformation implemented by computation program 506 has the characteristic that it is difficult to reverse, 
i.e., it is difficult ("computationally infeasible") to compute or otherwise find another, different instruction/data block 
500A that produces the same authentication code 506. Such transformations are commonly referred to as "one way 

10 hash' transformations or "cryptographic checksums." The particular one-way function used is not a part of this invention. 
There is a wealth of information available to those skilled in the art regarding suitable one-way transformations. See, 
for example, Schneier, Bruce, Applied Cryptography , Chapter 18 ("One Way Hash Functions"), pages 429-459 and 
associated bibliography (2d Ed., Wiley & Sons 1996). 

In this particular embodiment, the authentication code 508 outputted by the transformation is much smaller than 

is the instruction/data block 500 (i.e., the one-way function acts as a "compression" function). Those skilled in the art will 
understand that the length of authentication code 508 should be sufficient to minimize the threat of "brute force" attacks. 
Due to the information loss between the input and output of the one-way function, the one-way function cannot in this 
example be considered an "encryption" -- since it is not possible to recover the original block 500 from the authentication 
code 508 even if the transformation can be reversed (as discussed above, the transformation in this example is pref- 

20 erably one-way, not reversible). 

In the particular example process shown in Figure 15, the computation program 506 defines a family of mathe- 
matical (or other) one-way transformations. An authentication key 504 is used to select a particular transformation from 
this family of transformations. Figure 15 shows for illustration purposes only the authentication key 504 as being a 
physical key - but the key comprises a digital bit string. In this example, the authentication key 504 does not operate 

25 as an "encryption" key or "decryption" key, but instead is used to select which particular one-way transformation the 
computation program 506 performs. 

The manufacturing facility selects a value for authentication key 504. The manufacturing facility stores the authen- 
tication code 508 resulting from the one-way function in the read only memory (ROM) of a security microprocessor 
chip 152. The manufacturing facility also stores, in this security microprocessor chip ROM, the authentication key 504 

30 the manufacturing facility used to select the particular one-way transformation functions the computation program 506 
used to generate the authentication code 508. The manufacturing facility also stores a security program in the security 
microprocessor chip ROM. 

Because the security microprocessor chip stores the computed authentication code 508 corresponding to the 
instruction/data block 500 of game program 502, the security microprocessor chip 152 is matched to work with this 
35 particular game program. If the manufacturing facility inserts the same instruction/data block 500 into several different 
video game programs or titles, then the same security chip 152 can work with each of those video game programs or 
titles. On the other hand, video game programs having different instruction/data blocks 500 will require different security 
microprocessor chips 1 52 (and associated different authentication codes 508). 

40 Example Embodiment to Test Whether The Video Game Program and External Storage Unit Security 
Microprocessor Chip Match 

Figures 1 6A-1 6F show an example embodiment of an overall video game security arrangement that tests whether 
the video game program and storage unit security microprocessor chip 1 52 match. As shown in Figure 1 6A, an authentic 

45 external storage unit 54 includes: (a) a storage medium (e.g., a mask ROM or other data storage medium) 76 containing 
a video game program 502 with its included instruction/data block 500; and (b) a corresponding security microprocessor 
chip 1 52 containing the authentication key 504 used by the manufacturing facility, the authentication code 508 computed 
by the computation program 506 at the manufacturing facility, and a security program. In this example, the main unit 
52 determines whether the security microprocessor chip 152 appropriately corresponds to the video game program 

50 before it allows the video game program 502 to play. 

In this example, when the customer wants to play a particular video game, he or she connects the external storage 
unit 54 containing the desired video game program 502 and associated corresponding security microprocessor chip 
152 to the main unit 52 (see Figure 16A). Upon power-up, the external storage unit security microprocessor chip 152 
sends the authentication key 504 and the authentication code 508 to the main unit peripheral interface 1 38 (see Figure 

55 16B). Details of an exemplary peripheral interface 138 are shown for example in Figures 3A and 7. The peripheral 
interface 138 sends the authentication key 504 to the main processor 100 (see Figure 16C). However, in this example, 
the peripheral interface 1 38 retains the authentication code 508, and does not reveal it to the main processor 100. 
The peripheral interface 138 preferably already has a copy of the same computation program 506 (or another 
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program capable of performing the same one-way transformation (s)) used at the manufacturing facility. The peripheral 
interface 138 may, in one example, include a boot ROM 262 (see Figure 7) that stores this computation program 506. 
The computation program 506 is executed by the main processor 100 in this example. This computation program 506 
may, for example, be executed out of boot ROM 262, or if execution speed is a concern, it may be loaded into a random 

s access memory (RAM) accessible by the main processor 1 00 (for example a cache memory the main processor has 
read/write access to). The main processor 1 00 also loads the game program instruction/data block 500 from the external 
storage unit 54 into RAM (Figure 16C). The computation program 506 may for example, specify the location and/or 
length of the program instruction/data block 500 within the overall video game program 502. 

In this example, the main processor 100 performs exactly the same computation the manufacturing facility per- 

10 formed when it made the security microprocessor chip 1 52, based on the very same inputs (see Figure 1 6D). Assuming 
the external storage unit 54 is authentic, the main processor 100 has the same computation program 506 and authen- 
tication key 504 used at the manufacturing facility, and can therefore perform the same one-way transformation the 
manufacturing facility performed. The main processor 100 also has the same video game program instruction/data 
block 500 the manufacturing facility used as input to the one-way transformation. The main processor 100 should 

is therefore get the same authentication code result as the manufacturing facility got (or one that bears a predetermined 
relationship with the authentication code the manufacturing facility calculated). If the result is different (e.g., does not 
bear a predetermined relationship), the main unit 52 does not execute the video game program 502. 

In more detail, the main processor 100 in this example uses authentication key 504 to select a particular one-way 
function from a family of functions defined by the computation program 506. Main processor 100 executes the com- 

20 putation program 506 to convert the video game program instruction/data block 500 to an authentication code 510 ("A- 
code") (Figure 16D). Assuming the external storage unit 54 is authentic, the authentication code "A-code"' 510 the 
main processor 100 computes will be identical to (or bear a predetermined relationship with) the authentication code 
"A-code'' 508 the manufacturing facility computed when the security microprocessor chip 152 was manufactured. The 
two values should be the same in this particular example because; (a) the A-key 504 the security microprocessor chip 

2S 1 52 supplies to the main processor 100 is the same one used at manufacture time; and (b) the instruction/data block 
500 input is the same one used at time of manufacturing; and (c) the one-way function the main processor performs 
is the same one the manufacturing facility used to compute the authentication code 504 stored in the security micro- 
processor chip 152. 

In this example, the main processor 100 sends the authentication code 'A-code' " 510 it has calculated to the 

30 peripheral interface 138 (Figure 16E). The peripheral interface 138 can be trusted to accurately compare the authen- 
tication code "A-code"* 510 supplied by the main processor 100 with the authentication code "A-code" 508 supplied 
by the security microprocessor chip 152 (Figure 16E). If the two authentication codes are the same (or, in another 
example, if they bear a predetermined relationship to one another), the peripheral interface 138 is satisfied that the 
external storage unit's security microprocessor chip 152 matches at least block 500 within the video game program 

35 502, and the peripheral interface 138 issues a "go" signal. 

If there is no match (or predetermined relationship) between the two authentication codes 508, 510, this means 
the external storage unit 54 is not authentic For example, if there is no match, someone may be trying a "decoy" attack 
in which the security microprocessor chip 152 is being used with a different (unmatched) video game program. For 
example, the video game player may be using a "y" adapter to simultaneously connect, to the main unit 52, a security 

40 microprocessor chip 1 52 from an authentic external storage unit 54 and a bogus storage medium 76 having no (or a 
different) associated security microprocessor chip. In this example, the peripheral interface 1 38 will detect this situation 
and prevent the main unit 52 from playing the video game program. For example, the peripheral interface may reset 
or interrupt the main processor 100 and other components (e.g., the graphics coprocessor) to prevent the main unit 
from operating in this instance. See Figures 3A-3B and associated discussion concerning details of system "reset" and 

45 "NMl" operation. 

Example Embodiment to Further Test Whether The Video Game Program is Authentic 

The embodiment shown in Figure 17 may provide additional methods to enforce the security level. In this Figure 
so 17 embodiment, the main unit 52 authenticates some or all additional portions of the video game program. In our 
example, main unit 52 may use a software-based authentication mechanism to perform this authentication step. 

in one example arrangement, the peripheral interface 1 38 may execute, using its own internal microprocessor 250 
and ROM 252 (see Figure 7), a software authentication program to authenticate the video game program. In another 
example arrangement, the peripheral interface 1 38 may supply a software authentication program from boot ROM 262 
55 to the main processor 100 for execution. In still another example arrangement, the video game program 502 may be 
self -authenticating in the sense that one part of the program authenticates another part (or the rest of) the video game 
program. For example, it is well known that the one-way function and associated comparisons of the type shown in 
Figures 1 6A-1 6F can be used to authenticate (and perform an integrity check on) the instruction/data block 500. Once 
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such an authentication/integrity check has been completed on instruction/data block 500, the main processor 100 may 
then execute that block 500 to authenticate some or all additional portions of the video game program 502. 

The particular algorithm or steps used to authenticate the video game program 502 is not a part of this invention. 
Those skilled in the art are aware of many different techniques for authenticating computer software. Different tech- 

5 niques or combinations of techniques can be used for different video games or game titles. One or more techniques 
may be chosen based on a variety of different factors including for example: the length of the video game program; 
the amount of time available for video game program authentication (generally, delay before starting game play should 
be minimized, consistent with security concerns, so the customer doesn't have to wait a long time before game play 
begins); the amount of storage space available in the storage medium 76 to store authentication procedures; whether 

10 the authentication should be performed a single time, more than once or repeatedly; the level of security required or 
desired; etc. By way of non-limiting example, the following are some of the many techniques known by those skilled 
in the art for authenticating software: 

• Confirming the presence of one or more predetermined codes hidden in predetermined places within the software; 

15 

• Performing one or more one-way functions on some or all of the software, and comparing the one-way function 
results with results calculated beforehand at time of manufacture. 

• Decrypting software instructions and/or data using a symmetric or asymmetric key, and confirming that the de- 
20 cryption results are intelligible, executable and/or match values determined at time of manufacturing. 

• Using a symmetric or asymmetric key, decrypting one or more encrypted hash values embedded within the soft- 
ware, and confirming that the decrypted hash value(s) match corresponding hash value(s) calculated at run time 
based on predetermined portions (or the entirety) of the video game program. 

25 

• Authenticating one or more digital certificates present within the software. 

• Techniques described in commonly assigned U.S. Patent No. 5,134,391. 

30 Example Embodiment to Test Whether The Security Microprocessor Chip is Authentic 

The embodiment of Figures 16A-16F could potentially be defeated by replacing the security microprocessor chip 
1 52 with a non-authentic component that supplies the correct authentication code 508 and authentication key 504. To 
guard against this threat, the Figure 18 video game security system embodiment can require the component that 
35 supplies the authentication code 508 and authentication key 504 to also conduct an endless series of data exchanges 
with peripheral interface 138. The embodiment shown in Figure 18 allows the peripheral interface 138 to authenticate 
the external storage unit security microprocessor chip 1 52, and can also allow the external storage unit 54 to authen- 
ticate the main unit peripheral interface 138. 

The data exchanges between the external storage unit security microprocessor chip 152 and the peripheral inter- 
40 face 138 may be based on security programs stored in the security microprocessor chip 152 and in the peripheral 
interface 138. Each of these security programs may perform calculations based on secret, complex algorithms that 
are difficult to ascertain merely by observing inputs and outputs. The calculations are not a part of this invention. Those 
skilled in the art will understand that any sufficiently complex, deterministic data transformation process csn be used 
The operation of these security programs may be similar or identical to what is desrr - -?d in r.onmo^ ssigned 
45 U.S. Patent No. 4,799,635 to Nakagawa. For exanv 

(1 } the mair -it peripK J interface 1 38 and th. . <ternal storage unit security microprocessor chip 1 52 may each 
synchronou calculate values using a secret, complex algorithm, 

so (2) the main unit peripheral interface 1 38 and the external storage unit security microprocessor chip 1 52 may each 

send some or all of their calculated values to the other chip exactly at the time the other chip expects to receive 
the values, 

(3) the main unit peripheral interface 1 38 and the external storage unit security microprocessor chip 1 52 may each 
ss receive, at exactly the right time, the values the other chip sends to it, 

(4) the main unit peripheral interface 1 38 and the external storage unit security microprocessor chip 1 52 may each 
compare the values they received with the value(s) they calculated internally, 
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(5) the main unit peripheral interface 1 38 and the external storage unit security microprocessor chip 152 may each 
enter an "endless loop" (thus ending the "conversation") if the comparison is unfavorable with the main unit 
peripheral interface 138 endless loop periodically disabling the main processor 100. 

s (6) the ongoing "conversation" between the peripheral interface 138 and the external storage unit security micro- 

processor chip 152 can be repeated over and over again - with the internal calculations based on new data 
calculated from the last "round" of calculations used to generate new values for the next data exchange. The time 
of each calculation can depend on the results of that "round 0 of the calculation to provide variable timing between 
data exchanges. 

10 

Further Embodiment 

Figure 1 9 is a simplified flowchart of a further embodiment of example security steps performed by main processor 
1 00. These steps may be performed by one or more computer programs the main processor 1 00 executes. The coding 

is details of such computer programs is not a part of this invention. 

Upon power on (Figure 19, block 702), main processor 100 executes an "IPI_r initialization routine that initializes 
the main processor 1 00 (Figure 1 9, block 704) and the graphics coprocessor 200 (Figure 1 9, block 706). For example, 
these steps may provide a minimal amount of initialization (e.g., set the main processor 1 00 to 16 or 32 bit operation) 
to get these components running. The "IPL1 " instructions may be stored within the peripheral interface boot ROM 262, 

20 and executed by Ihe main processor out of that boot ROM. 

Main processor 100 then begins to execute an "IPL2" routine. The IPL2 routine may also, in this example, be 
stored by the peripheral interface boot ROM 262. In one example, main processor 100 may execute the IPL2 routine 
from the boot ROM 262. It may be desirable to load the IPL2 routine into a RAM before executing it in order to increase 
execution speed. For example, in one example, there are several different cache RAMs in the main processor 100*s 

25 address space. These cache RAMs may, for example, be within the main processor 100 and/or the graphics coproc- 
essor 200. One of these cache RAMs can be used to store the IPL2 routine during execution. As well known to people 
skilled in the art, these techniques may be used in combination with any number of different additional techniques to 
provide added tamper-resistance and/or security against unauthorized access to the security software executing in 
the main unit. See for example the following documents describing techniques known to those skilled in the art: White 

30 et al, "ABYSS: A Trusted Architecture For Software Protection" and references cited therein (IEEE 1987); Tygar et al, 
"Dyad: A System For Using Physically Secure Coprocessors'* and references cited therein (CMU-CS-91-140R, Carn- 
egie-Mellon University 1991); U.S. Patent No. 5,537,544: U.S. Patent No. 5,533,123; and U.S. Patent No. 5,237 : 616. 

Main processor 100 receives the authentication key 504 from peripheral interface 138-the peripheral interface 
having previously received it from the external memory unit security microprocessor chip 152 (Figure 19, block 708; 

35 see Figures 1 6B, 16C). The peripheral interface 1 38 may also send the main processor 1 00 additional information at 
this time, including for example information indicating whether the external storage media 76 is a mask ROM or a bulk 
storage device. 

The main processor 100 loads the instruction/data block 500 (which in this example contains M IPL3" instructions) 
of a predetermined length from a predetermined location within the external storage medium 76. The main processor 

40 1 00 may load block 500 into a RAM accessible by the main processor, for example the same or different cache RAM 
storing the IPL2 instructions (Figure 19, block 710; see Figure 16C). Main processor 100 then performs a one-way 
function on the "I PL3" instruction/data block 500 using the authentication key 504 in order to generate an authentication 
code 510 about the "IPL3"data block 500 (Figure 19, block 71 2; see Figure 16D). Main processor 100 then sends the 
authentication code 510 it has calculated to the peripheral interface 138 via serial interface RAM 264 (Figure 19, block 

45 714; see Figure 16E and Figure 7). 

As described above, the peripheral interface compares the authentication code 510 the main processor 100 cal- 
culates with an authentication code 508 the external storage unit security microprocessor chip 152 supplies to the 
peripheral interface, lo determine whether there is a match (see Figure 16F; Figure 20A, blocks 812-814). In this 
example, if there is no match, the peripheral interface 138 sends a reset or NMI (non-maskable interrupt) signal to the 

50 main processor 100 -preventing it from proceeding. During the time the peripheral interface 1 38 is making its compar- 
ison, the main processor 100 waits and occasionally polls the peripheral interface (Figure 1 9, block 71 6). Upon receiving 
a n go° signal from the peripheral interface 138, the main processor 100 begins executing the °\PL3* instruction/data 
block 500 (Figure 19, block 718). 

As part of the "IPL3" routine, the main processor loads some (e.g., a fixed length predetermined block) or all of 

55 the video game program from the external storage medium 76 into RAM 300 (Figure 19, block 720). Main processor 
100 authenticates the game program using a software authentication technique (Figure 19, block 722; see Figures 17 
and 17A). Because the peripheral interface 138 verified the IPL3 instruction/data block 500, the IPL3 block may be 
trusted to perform this further game program authentication. If the authentication step fails, main processor 100 stops 
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operating and game play never begins. If the game program authentication step is successful, main processor 100 
sends a "go" signal to the peripheral interlace 1 38 (see Figures 17 and 17A), performs housekeeping functions (e.g., 
to clean away no longer need information in the various RAMs and registers), jumps to the game program in RAM 
(Figure 1 9, block 724), and begins executing the game program (Figure 1 9, block 726). Meanwhile, in response to the 

5 "go" signal the peripheral interface 138 receives from the main processor 100, the peripheral interface begins data 
exchange communications with the external storage unit security microprocessor chip 152 (Figure 19, block 726). 

Figures 20A and 20B show example steps performed by the peripheral interface 1 38 in this example embodiment, 
and Figure 21 shows example steps performed by the external storage unit security microprocessor chip 152. The 
steps shown in Figures 20A and 20B may be performed by a computer program the peripheral interface CPU 250 

10 executes, and the steps shown in Figure 21 may be performed by a computer program the external storage unit security 
microprocessor chip 152 executes. The coding details of such computer programs is not a part of this invention. 

Referring to Figure 20A, upon power on (Figure 20A, block 802), the peripheral interface 138 receives a cassette/ 
bulk code from the external storage unit security microprocessor 152 (see Figure 21 , blocks 904, 906, 908), and sends 
that code to the main processor 100 (Figure 20A, blocks 804, 806). The external storage unit security microprocessor 

is chip 1 52 then sends to the peripheral interface 1 38, and the peripheral interface receives, the authentication code 508 
from the external storage unit security microprocessor chip 152 (Figure 20A, block 808; Figure 21, block 910). The 
external security microprocessor chip 152 also sends to the peripheral interlace 138, and the peripheral interface 
receives, an authentication key 504 (Figure 21, block 911; Figure 20A, block 810). Peripheral interface 138 passes 
this A-key 504 along to the main processor 1 00 (Figure 20A, block 810). 

20 The peripheral interface 1 38 then receives the authentication code 510 calculated by the main processor 100 in 

Figure 19, block 712 (Figure 20A, block 812), and compares the authentication codes 508, 510 received from the 
external storage unit security microprocessor chip 152 and the main processor, respectively (Figure 20A, block 814). 
If these two authentication codes do not match, the peripheral interface 1 38 enters an infinite loop (Figure 20C, block 
890). If there is a match, the peripheral interface 138 sends a "go" signal to the main processor (Figure 20A, block 

25 816), and waits to receive a "go* signal from the main processor upon the main processor's completion of the game 
program authentication step (Figure 20A, block 818; see Figure 19, block 722). Upon receiving the "go" signal from 
main processor 100 ("yes" exit to decision block 818, Figure 20A), peripheral interface 138 sends a "go 0 signal to the 
external storage unit security microprocessor chip 1 52 (Figure 20A, block 820; Figure 21 , block 912). This "go" signal 
synchronizes the peripheral interface 138 and the security microprocessor chip 152. 

30 Once synchronization has been established, the peripheral interface 1 38 and external storage unit security micro- 

processor chip 152 begin communicating (see Figure 18). In this example, the peripheral interface 138 and external 
storage unit security microprocessor chip 1 52 can communicate requests and commands as well as data. The periph- 
eral interface 1 38 can send two different requests and a command to the external storage unit security microprocessor 
chip 152: 

3S 

• a timer request, 

• a test-caic request, 

• an SEC communication command. 

40 The timer request causes the external storage unit security microprocessor chip 152 to wait a certain time period and 
then send a "go" signal to the peripheral interface 138. The test-calc request causes the external storage unit security 
microprocessor chip 152 to receive data from the peripheral interface 138, transform the data, and return the trans- 
formed data to the peripheral interface. The SEC communication command causes the external storage unit security 
microprocessor 152 to calculate a value based on an internal calculation, receive a value from the peripheral interface 

45 1 38, send the calculated value to the peripheral interface, and compare the value it received from the peripheral inter- 
face with the value it has calculated internally (the values exchanged in the different directions are different to avoid a 
"play back" attack). 

In this example, the peripheral interface 138 then determines whether the system "reset" signal is on (Figure 20B, 
block 822). If the reset signal is on ("yes" exit to decision block 822), peripheral interface 1 38 sends a timer request to 

50 the external storage unit security microprocessor chip 1 52 (Figure 20B, block 824). The peripheral interface 138 then 
waits to receive a responsive "go" signal from the external storage unit security microprocessor chip 1 52 (Figure 20B, 
block 826). Meanwhile, in response to the received "timer" request, the external storage unit security microprocessor 
chip 152 waits a certain time period and then sends a "go" to the peripheral interface 138. 

If the "test-calc" flag has been set (Figure 20B, decision block 828), the peripheral interface 138 sends a "test- 

55 calc" request to the external storage unit security microprocessor chip 152 (Figure 20B, block 830). The peripheral 
interface 138 then receives input data from main processor and sends that data to the external storage unit security 
microprocessor chip 152 (Figure 20B, block 834). In response to the n test-calc"request, the external storage unit se- 
curity microprocessor chip 1 52 receives the input data from the peripheral interface 138 (Figure 21 , block 920), trans- 
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forms that input data into a result data (Figure 21 , block 924), and sends the result data back to the peripheral interface 
1 38 (Figure 21 , block 926). The particular transformation used to calculate the data is not a part of this invention; any 
suitable calculating function can be used. The peripheral interface 1 38 receives the result data from the external storage 
unit security microprocessor chip 152(Figure 20B, block 838), and sends the result data to the main processor 100 

5 (Figure 20B, block 840). This test-calc operation may be used to allow the video game program 502 to authenticate 
the external storage unit security microprocessor chip 152. For example, the game program 502 can determine whether 
chip 152 performs a authentic transformation to calculate the data the game program provides. 

If the test-calc flag is not on (Figure 20B, block 828, "no" exit), then the peripheral interface 138 sends an "SEC 
communication" to the external storage unit security microprocessor chip 152 (Figure 20C, block 842). In response to 

10 this SEC communicaiton, the peripheral interface 138 and the external storage unit security microprocessor chip 152 
each perform the steps described in the above-referenced Nakagawa patents. Specifically, they each calculate an 
internal code (Figure 20C, block 844; Figure 21, block 928); they each send a part of the code they have calculated 
to the other (Figure 20C, block 846; Figure 21 , block 932); they each receive the information sent by the other (Figure 
20C, block 848; Figure 21, block 930); and they each compare the information they have received with information 

is they have calculated internally (Figure 20C, block 850; Figure 21 , block 934). If either the peripheral interlace 138 or 
the external storage unit security microprocessor chip 152 tails to receive the information it expects to receive, the 
device enters an infinite loop (Figure 20C, block 890; Figure 21, block 936). Whenever the peripheral interface 138 
enters an endless or infinite loop, it sends a "reset" or non-maskable interrupt to the main processor 100 to prevent 
game play from proceeding (Figure 20C, block 890). 

20 While the invention has been described in connection with what is presently considered to be the most practical 

and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, 
but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit 
and scope of the appended claims. 

25 

Claims 

1. For use in a video game system having an external memory for storing a video game program, a game microproc- 
essor for executing said video game program, at least one player controller operable by a player for generating 

30 video game control signals, a coprocessor, coupled to said game microprocessor, for cooperating with said game 

microprocessor to execute said video game program, said coprocessor being operable to generate at least one 
player controller related command requesting an operation be performed relating to said video game control signals 
generated by said at least one player controller; a peripheral processing memory device for storing a first set of 
instructions for controlling the performance of said operation relating to said video game control signals identified 

35 by said player controller related command, and a second set of instructions for authenticating said external memory; 

and 

a microprocessor for executing said first set of instructions and said second set of instructions. 

2. For use with a video game system console having a game microprocessor for executing a video game program 
40 and a coprocessor coupled to said game microprocessor for cooperating with said game microprocessor to execute 

said video game program, a portable storage device for controlling the operation of said video game system console 
comprising: 

a memory media lor storing video game instructions and graphics and sound data; 
45 a multiplexed bus, coupled in use to said coprocessor, for transmitting address signals in parallel to said 

memory media and for receiving information accessed from said memory media; 

addressing logic circuitry for gating address signals received from said bus to address said memory media; 
readout circuitry for coupling information readout of said memory media to said multiplexed bus; and 
a memory media authenticating processor for transmitting and receiving information to and from said video 
50 game system console. 

3. A video game system comprising: 

a main processor; 
55 a 3D graphics coprocessor; 

a peripheral interface coupled to at least one of the main processor and the 3D graphics coprocessor; and 
a connector adapted, in use, for accepting an external storage unit, the storage unit including video game 
program that controls at least one of the main processor and the 3D graphics coprocessor to generate vide- 



25 



EP0 875 816 A2 

ographics and sound, 

wherein the peripheral interface includes a structure that at least in part authenticates the video game program. 

4. A system as in claim 3 wherein the main processor performs a calculation based at least in part on the video game 
program, and provides the output of the calculation to the peripheral interface. 

5. A system as in claim 4 wherein the external storage unit includes a security microprocessor that stores a calcu lation 
result, and the peripheral interface obtains the stored calculation result from the security microprocessor and com- 
pares the obtained calculation result with the result of the calculation performed by the main processor 

6. An external storage unit for use with a video game system of the type comprising a main processor, a 3D graphics 
coprocessor, a peripheral interface coupled to at least one of the main processor and the 3D graphics coprocessor, 
and a connector adapted, in use, for accepting an external storage unit, the storage unit including: 

a storage medium that stores a video game program for, in use, controlling at least one of the main processor 
and the 3D graphics coprocessor to generate videographics and sound, and 

a security microprocessor that stores at least one authentication value corresponding to the video game pro- 
gram, 

wherein the video game program and the security microprocessor are matched. 

7. An external storage unit for use with a video game system of the type comprising a main processor, a 3D graphics 
coprocessor, a peripheral interface coupled to at least one of the main processor and the 3D graphics coprocessor, 
and a connector adapted, in use, for accepting an external storage unit, the storage unit including: 

a storage medium that stores a video game program for, in use, controlling at least one of the main processor 
and the 3D graphics coprocessor to generate videographics and sound, and 

a security microprocessor that stores at least one authentication value corresponding to the video game pro- 
gram, the security microprocessor also storing a security program, the security microprocessor, in use, pro- 
viding the authentication value to the main processor and repeatedly providing security data to the peripheral 
interface for authentication purposes. 

8. An external storage unit for use with a video game system of the type comprising a main processor, a 3D graphics 
coprocessor, a peripheral interface coupled to at least one of the main processor and the 3D graphics coprocessor, 
and a connector adapted, in use, for accepting an external storage unit, the storage unit including: 

a storage medium that stores a video game program for, in use, controlling at least one of the main processor 
and the 3D graphics coprocessor to generate videographics and sound, and 
a security microprocessor matched to the video game program, 

wherein the video game program includes at least one data block that is paired with at least one value stored 
within the security microprocessor, and the security microprocessor, in use, authenticates the peripheral in- 
terface. 

9. An external storage unit for use with a video game system of the type comprising a main processor, a 3D graphics 
coprocessor, a peripheral interface coupled to at least one of the main processor and the 3D graphics coprocessor, 
and a connector adapted, in use, for accepting an external storage unit, the storage unit including: 

a storage medium that stores a video game program for, in use, controlling at least one of the main processor 
and the 3D graphics coprocessor to generate videographics and sound, and 
a security microprocessor, 

wherein the video game program stored within the storage medium includes at least a first portion used to 
authenticate at least a second portion of the video game program, and the security microprocessor includes 
information for, in use, authenticating the video game program first portion. 

10. An external storage unit for use with a video game system of the type comprising a main processor, a 3D graphics 
coprocessor, a peripheral interface coupled to at least one of the main processor and the 3D graphics coprocessor, 
and a connector adapted, in use, for accepting an external storage unit, the storage unit including: 

a storage medium that stores a video game program for, in use, controlling at least one of the main processor 
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and the 3D graphics coprocessor to generate videographics and sound, and 

a security microprocessor for, in use, receiving requests and commands from the peripheral interlace, the 
security microprocessor, in use, receiving and processing at least a timer request, a test-calc request, and a 
secure communication command. 

5 

11. An external storage unit as in claim 10 wherein the security microprocessor, in use, waits a certain time period 
and then sends a go signal to the peripheral interface upon receipt of the timer request. 

12. An external storage unit as in claim 10 wherein the security microprocessor, in use, receives data from the periph- 
10 eral interface, transforms the received data, and returns the transformed data to the peripheral interface upon 

receipt of the test-calc request. 

13. An external storage unit as in claim 10 wherein the security microprocessor, in use upon receipt of the secure 
communication command, calculates a value based on an internal calculation, receivs a value from the peripheral 

15 interface, sends the calculated value to the peripheral interface, and compares it received from the peripheral 

interface with the value it has calculated internally 

14. In a video game system for use with an external storage unit including a security chip and a storage medium, the 
storage medium storing a video game program, the video game system including a peripheral interface for, in use, 

20 communicating with the external storage unit security chip, the peripheral interface performing the following steps: 

(a) authenticating at least one of the security chip and the storage medium; 

(b) securely confirming a match between the security chip and the storage medium; and 

(c) disabling the video game system from operating upon failure of either step (a) and step (b). 

25 

15. A method as in claim 14 wherein step (a) includes comparing an authentication code supplied by the security chip 
with a code derived from the video game program. 

16. A method as in claim 14 wherein step (a) includes checking data transmitted by the security chip with internally 
30 calculated data. 

17. A method as in claim 14 wherein step (b) includes the step of performing a one-way transformation on at least a 
portion of the video game program. 

35 18. A method as in claim 14 wherein step (b) includes the step of comparing at least one element derived from the 
video game program with at least one element derived from the security chip. 

19. In a video game system for use with an external storage unit including a security chip and a storage medium, the 
storage medium storing a video game program, the video game system including a main processor and a peripheral 

40 interface for, in use, communicating with the external storage unit security chip, the video game system performing 

the following steps: 

(a) using the peripheral interface to authenticate the security chip; 

(b) using a combination of the peripheral interface and the main processor to authenticate a first part of the 
45 video game program; and 

(c) using the main processor to authenticate a further part of the video game program. 

20. A method as in claim 19 wherein step (c) includes using the first part of the video game program to authenticate 
the further part. 

so 
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